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Vision  Algorithms  and  Psychophysics 


1.0  Introduction 


“Seeing”  requires  the  construction  of  symbolic  descriptions  of  the  external  world. 
The  most  useful  symbolic  descriptions  will  be  representations  for  each  of  the 
various  objects  in  the  three-dimensional  scene.  These  objects,  in  turn,  may  be 
broken  down  further  into  more  detailed  modular  representations  that  may  include 
the  various  attributes  of  each  object  such  as  its  color,  texture,  or  the  shape  and 
relative  motion  of  its  parts.  These  latter  properties  are  thus  our  basic  building 
blocks  from  which  more  complicated  descriptions  are  built.  Vision  understanding 
requires  showing  how  such  object  properties  can  be  represented  internally,  and 
how  they  can  be  brought  together  to  create  a  description  suitable  for  recognition 
or  manipulation.  This  then,  is  our  goal:  to  propose  and  implement  a  scheme  for 
representing  3D  shapes  in  a  manner  suitable  for  recognition. 

To  reach  this  goal,  the  research  has  proceeded  along  several  parallel,  but 
complementary  tracks.  The  first  is  the  development  of  a  theory  for  representing 
3D  shapes,  or  their  2D  projections  onto  the  image.  Here  we  offer  two  possibilities 
for  representing  3D  shapes  (Gaussian  curvature  and  Process-based  descriptions) 
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and  also  two  proposals  for  representing  2D  shapes  (curvature-based  codons  and 


the  alignment  method).  None  of  these  theories  necessarily  excludes  using  the  >op/ 
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other.  One  element  common  to  all  the  proposals  is  the  key  role  played  by  cur¬ 
vature  or  curvature  extrema — a  role  supported  by  our  psychophysical  studies. 

All  present  theories  of  shape  recognition  require  that  the  shape  be  isolated 
from  its  background.  Hence  a  second  research  track  has  been  the  identification  of 
candidate  "objects”  in  images,  using  color,  visual  motion,  stereo,  or  significant 
groupings  of  special  image  features  (such  as  co-circular  or  parallel  segments). 
Again,  as  in  the  shape  recognition  proposals,  the  plausibility  of  our  tentative 
solutions  are  supported  both  by  meudiine  implementations  and  by  visuzil  psy¬ 
chophysics. 

2.0  Representing  2D  Shapes 

Line  drawings  and  silhouettes  testify  to  the  power  of  the  shape  of  a  contour 
as  a  means  for  object  recognition.  As  illustrated  by  Attneave’s  famous  "cat” 
(and  also  Figure  1),  much  of  this  information  about  shape  is  carried  by  the 
curvature  extrema  (Attneave,  1954;  Fischler  &  Holies,  1983;  Resnikoff,  1987). 
One  reason  why  curvature  extrema  are  critical  to  shape  recognition  is  that  they 
divide  the  outline  into  its  parts  (HofiTman  k  Richards,  1982;  1984).  As  illustrated 
in  Figure  2,  when  objects  are  created  by  interpenetrating  parts  or  protrusions, 
a  curvature  extrema  in  the  form  of  s  concavity  will  appear  in  the  image.  Such 
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Figure  1  Curvature  extrema  carry  eignificant  mformation  about  shape. 


Figure  3  The  definition  of  a  part  boundary  is  derived  from  the  transversal 
property  that  two  interpenetrating  surfaces  will  meet  at  a  concave  disconti¬ 
nuity. 

concavities  thus  provide  a  powerful  index  into  any  part-based  object  recognition 
scheme. 

A  second  reason  for  emphasizing  curvature  as  a  shape  primitive  is  that  the 
sign  of  curvature  of  a  silhouette’s  contour  in  the  image  immediately  tells  the 
viewer  the  intrinisic  3D  shape  of  the  object  in  the  world  (Koenderink  &  van 
Doom,  1980,  1981,  1982,  1987).  For  example,  a  piece  of  silhouette  having  pos¬ 
itive  curvature  must  arise  from  a  3D  surface  with  positive  Gaussian  curvature. 
Such  imaging  properties  mean  that  very  powerful  infererces  about  SD  shapes 
can  be  made  directly  from  2D  image  contours.  Consequently,  in  1982  Hofiinan 
and  Richards  proposed  that  the  first  abstract  description  of  the  2D  image  curves 
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Figure  S  The  primitive  codon  types.  Zeros  of  cnrvntnre  ere  indicated  by 
dots,  minima  by  slashes.  The  str^ght  line  (oo)  is  a  degenerative  case  included 
for  completeness,  although  it  is  not  treated  in  the  text.  (See  Richards  <k 
Hoffman,  1984,  for  definitions.) 

should  be  based  upon  the  singularities  of  curvature — the  positive  and  negative 
extrema  and  the  inflections  of  zero  curvature.  Noting  that  the  extrema  of  nega¬ 
tive  curvature  (i.e.  the  concavities)  correspond  to  the  part  boundaries,  it  was  easy 
to  show  that  there  would  only  be  five  primitive  or  different  elemental  shapes  for 
representing  smooth  plane  curves.  These  were  called  “codons"  (Figure  3).  Any 
smooth  curve  could  then  be  characterized  quite  simply  in  terms  of  the  sequence 
of  its  codons.  Curves  with  identical  codon  sequences  would  then  be  topologically 
identical,  and  hence  “similar”  to  the  human  eye  (see  Figure  4).  The  scheme 
offered  a  ready  explanation  for  figure-ground  reversals  where  the  same  image 
contour  “looked  different”  depending  upon  which  side  of  the  curve  was  taken 
as  figure  (see  Figure  5  and  cover).  The  explanation  was  simple;  a  reversal  of 
figure-ground  caused  maxima  of  curvature  to  become  minima,  thus  switching 
the  location  of  the  part  boundaries  along  the  curve  (and  hence  also  the  sign  of 
Gaussian  curvature  and  the  intrinsic  3D  shapes). 
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Figure  4  Skewed  symmetry  is  obvions  in  the  codon  string  bec&nse  hslf  the 
sequence  is  reversed,  ignoring  the  sign  of  the  codon  (ieft  frame).  Figure- 
ground  reversal  changes  the  codon  string  because  maxima  and  minima  of 
curvature  are  exchanged,  providing  a  simple  explanation  for  Rubin’s  face- 
vase  iUusion.  (Adapted  from  Hoffman,  1983.) 

L 

Figure  6  Partitioning  plane  curves  into  its  parts.  Extrema  of  negative 
curvature  are  indicated  by  slashes.  Arrows  indicate  direction  of  traversal  of 
curve.  The  figure  is  taken  to  be  to  the  left  of  the  direction  of  traversal. 


A  sequence  of  codons  is  a  very  abstract  description  of  a  plane  curve.  This 
has  advantages  as  a  first  index  into  shapes  (see  Figure  6),  but  obvious  disadvan¬ 
tages  when  metrical  or  relational  information  needs  to  be  specified.  Recently, 
Ullman  (1986)  and  Huttenlocher  te  Ullman  (1987)  have  proposed  a  2D  shape 
recognition  scheme  that  supplements  the  curvature  primitives  with  relational  in¬ 


formation.  In  this  scheme,  Ullman  uses  the  fact  that  rigid  3D  objects  do  not 
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Figure  9  A  sloppy  stereogram,  where  images  presented  to  each  eye  (upper 
two  panels)  include  shapes  that  underwent  distortions,  changes  in  sise  and 
articulations.  Matching  I7  shape  using  codons  b  robust  to  these  dbtortions, 
just  as  matching  to  memory  must  be  for  recognition.  (From  Richards,  1988.) 


change  their  appearance  in  arbitrary  ways  as  they  are  rotated,  and  hence  the  set 
of  transformations  from  object  to  image  is  restricted.  Indeed,  only  three  distinct 
feature  points  are  needed  to  "undo”  the  unknown  rotation,  translation  and  scale 
transformations,  given  the  object  model,  thus  permitting  unique  object-to-model 
alignment  (for  rigid  objects). 


3.0  Processes  and  Axes 


A  second  mqjor  approach  to  representing  2D  shapes  is  process-based  descriptions. 
Again,  curvature  and  curvature  extrema  play  a  key  role  (Leyton,  1987,  1988, 
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1989;  Milios,  1989).  The  argument  follows  from  the  notion  that  when  shapes 
are  created  by  either  internal  or  external  forces,  then  these  forces  are  maximal 
at  a  point,  not  a  region,  and  consequently  create  a  curvature  extremum  on  the 
surface  of  the  shape.  ^  As  the  force  is  applied  over  time,  this  extremum  will  sweep 
out  a  trajectory  in  space.  With  rather  simple  but  plausible  assumptions,  Leyton 
argues  that  this  trajectory  will  correspond  to  the  axis  of  symmetry  of  the  shape. 
Hence  the  symmetry  axes  of  a  shape  reflect  the  process  history  of  that  shape. 
The  inference  from  curvature  extrema  to  processes  thus  entails  two  stages: 

curvature  extrema  -♦  symmetry  axes  -♦  processes. 

As  we  hinted  above,  the  intermediate  role  of  the  symmetry  axes  in  the  process 
description  is  crucial.  Two  kinds  of  curvature  computations  enter  here.  First, 
as  Leyton  proves  with  his  Symmetry  Curvature  Duality  Theorem  (1987),  each 
curvature  extrema  corresponds  to  the  termination  of  a  unique  differential  axis 
of  symmetry.  Second,  these  axes  of  symmetry  are  defined  by  pairs  of  tangent 
vectors  which  are  mirror  symmetric  on  circles — a  construction  we  will  use  later  to 
compute  curvature.  This  construction  is  illustrated  in  Figure  7.  The  differential 
symmetry  axis  of  two  segments  of  a  curve  is  simply  the  locus  of  the  midpoint  of 

^Kfore  properly,  the  application  of  a  point  force  to  an  (elliptical)  surface  patch  will  cre¬ 
ate  two  extremnm — first  an  hyperbolic  saddle  followed  by  the  appearance  of  Leyton’s 
elliptic  extremnm. 
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Figure  7  Two  curves  ci  &nd  23  th&t  have  symmetric  tangent  vectors  at  A 
and  B.  The  SAT-axis  is  the  loci  of  circle  centers  (represented  by  the  dots 
shown).  The  SLS-axis  and  PISA-axis  would  be  the  locus  of  points  P  and  Q, 
respectively. 


the  circles  tangent  to  the  curve  (SAT)  or,  alternately,  some  other  fixed  point  on 
the  circle  or  one  of  its  chords  (Blum,  1973;  Pizer  et  al.,  1987). 

The  obvious  advantage  of  including  axes  in  shape  representations  is  that  the 
size  orientation  and  relations  between  parts  can  be  specified  more  fully  (Marr  ii 
Nishihara,  1978).  A  sequence  of  codons  alone  lacks  this  information.  However, 
as  explored  rather  thoroughly  by  Leyton  (1988),  there  is  a  close  tie  between  the 
codon  and  process  or  axial-based  descriptions.  We  shall  return  to  this  briefly 
later. 


4.0  Computing  2D  Image  Curvature 

Present  algorithms  for  computing  curvature  along  an  image  contour  can  be  di¬ 
vided  into  three  categories,  (1)  the  differentiation  of  an  edge  list  of  the  con¬ 
tour;  (2)  the  construction  of  circles  tangent  to  two  points  along  the  curve  (co- 
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circularity);  and  (3)  symbolic  grouping  of  cert^  image  tokens.  Our  laboratory 
has  stressed  the  first  approach  (although  see  Saund,  1988  for  work  on  the  latter). 

4.1  Edge  List  or  Contour  Differentiation 

In  machine  vision,  once  a  blob  or  contour  is  isolated,  its  edge  list  can  be  numeri¬ 
cally  differentiated  twice  to  yield  curvature  (Dawson  ii  lYeese,  1984;  Richards  et 
al.,  1986).  Two  scale  issues  arise  in  this  process.  First,  the  blob  or  contour  is  cus¬ 
tomarily  found  using  the  Laplacian  of  Gaussian  or  some  similar  two-dimensional 
smoothing  function  whose  scale  is  chosen  rather  arbitrarily.  Second,  the  resulting 
edge  list  itself  must  be  smoothed  when  constructing  tangents  to  the  curve,  and 
a  scale  must  also  be  set  for  the  curvature  calculation,  which  customarily  entails 
simply  running  an  "edge”  or  first  derivative  operator  over  a  plot  of  tangent  ori¬ 
entation  versus  edge  position.  Alternatively,  all  of  these  operations  can  be  done 
locally  using  two  dimensional  masks  (Koenderink  it  Richards,  1988) — but  again 
the  spatial  scale  of  the  masks  must  be  chosen  in  advance.  To  represent  the  com¬ 
plete  spatial  structure  of  an  image  object,  the  computations  must  be  performed 
over  a  range  of  scales  (Witkin,  1983,  1984;  Koenderink,  1984;  Yuille  it  Poggio, 
1984).  Thus,  curvature  extrema  computed  across  scales  yield  a  rather  complex 
data  structure.  How  can  this  data  structure  be  simplified? 
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Figure  8  Pe&rs  with  different  snrfnce  textnree. 

Figure  8  illustrates  the  problem.  Let  the  silhouette  of  a  pear-shaped  object 
(A)  be  modified  to  have  either  a  sinustodal  ripple  (B),  prickles  (C)  or  a  composi¬ 
tion  of  prickles  and  ripples  (D).  In  spite  of  these  modifications  of  the  silhouette, 
the  underlying  pear  shape  is  still  apparent  to  us.  So  is  its  part  structure.  This 
suggests  that  the  coarser  scale  part  boundaries  of  (A)  are  still  recoverable  even 
when  corrupted  by  fine  textured  prickles  (C).  Most  algorithms  proceed  to  re¬ 
cover  the  coarse  scale  structure  of  the  corrupted  silhouette  (C)  by  blurring  (as 
in  a  Laplacian  Pyramid).  There  are  two  disadvantages  to  this  rather  obvious 
scheme:  (1)  the  resultant  data  structure  is  exceedingly  complex:  because  it  car¬ 
ries  many  2D  descriptions  of  the  image,  we  are  required  to  compute  curvature 
over  and  over  again  for  each  of  these  blurred  versions  of  the  image — each  for 
a  different  scale  curvature  operator!  (2)  Surprisingly,  sometimes  these  blurred 
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Fignre  9  When  the  top  two  shnpee  are  blnrred,  then  the  handle  either 
merges  with  the  ellipse  to  create  a  bnmp  (left)  or  dissociates  itself  to  create 
a  separate  smaller  ellipse  (right). 

versions  of  the  original  image  can  destroy  or  create  new  structures,  as  illustrated 
by  Figure  9.  If  this  figure  is  blurred,  the  “handle”  will  break  off  in  the  right-hand 
version  to  create  two  knobs,  whereas  in  the  left,  the  handle  merges  into  a  bump 
on  an  ellipse.  Neither  result  properly  describes  this  object  and  its  parts  as  we 
see  it. 

4.2  Fine  to  Coarse  Strategy 

As  an  alternate  approach,  we  propose  computing  tangent  orientations  along  the 
silhouette  only  at  the  finest  2D  scale,  >  nd  then  blurring  (or  grouping)  these 
fine-scale  tokens  by  using  larger  and  larger  curvature  operators.  This  approach 
greatly  simplifies  the  data  structure,  because  only  one  scale  space  is  constructed, 
not  a  multiplicity  of  scale  spaces.  The  result  resembles  Witkin’s  scale-space,  but 
in  the  curvature  domain.  Figure  10  Aows  this  method  applied  to  the  pears  (A) 
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Figtire  10  Curratare-space  uid  level-crossing  plots  for  A,  the  smooth  pear 
and  B,  the  rippled  pear  shown  in  Figure  8.  The  ordinate  shows  the  relative 
widths  of  the  curvature  operator;  positbns  on  the  abscissa  correspond  to 
positions  on  the  silhouette.  All  edge  lists  are  normalised  to  the  same  length. 
The  two  major  part  boundaries  are  indicated  by  the  vertical  Unes  through 
the  significant  extrema  of  negative  curvature.  The  vertical  ban  between  the 
two  graphs  indicate  the  region  within  which  extrema  are  not  marked,  unless 
a  plateau  appears  in  the  level-crossing  histogram.  These  ban  correspond  to 
509(  of  the  range  of  the  filter  width  indicated  by  the  level-crossing  histograms 
shown  as  insets  at  the  bottom.  These  graphs  show  only  the  fint  pass  at  part 
decomposition. 


and  (B).  An  edge  liet  is  created  for  the  silhouette,  and  tangents  are  computed 
at  the  finest  scale  for  each  point  on  the  edge  of  the  silhouette.  A  curvature 
operator  (1>D  edge  mask)  is  then  run  across  the  plot  of  tangent  orientation 
versus  edge  position  to  obtain  the  data  of  Figure  10.  Each  curve  in  this  figure 
shows  the  output  of  one  scale  curvature  mask  (sise  labelled  at  the  left)  versus 
position  in  the  edge  list.  At  the  finest  scale  curvature-mask  (eg.  1/8),  the  result 
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is  essentially  white  noise.  However,  as  the  size  of  the  curvature  mask  is  increased, 
more  and  more  structure  appears  in  this  kind  of  scale-space  plot.  For  exan.. 
at  scale  (1/2)  the  sinusoidal  ripples  in  pear  (B)  become  apparent.  And  finally, 
at  the  coarsest  scale  used  (A),  the  underlying  part  structure  is  obvious,  with 
both  pears  (A)  and  (B)  yielding  similar  graphs.  [(C)  also  exhibits  this  but  (D) 
will  not.]  Thus,  for  some  silhouettes  with  homogeneous  texture,  it  appears  that 
smoothing  over  a  fine-scale  tangent  distribution  can  be  equivalent  to  blurring 
the  2D  image  to  remove  fine  detul.  Under  these  conditions  it  is  not  necessary  to 
carry  a  multiplicity  of  blurred  versions  of  the  original  image,  with  the  operations 
of  Figure  10  applied  to  each.  Generally,  the  finest  scale  image  sufiices.  (Note, 
however,  that  for  Figure  8-D,  some  local  normalizations  of  the  texture  must  be 
included — see  Mokhtarian  ii  Mackworth,  1986;  Richards  et  al.,  1986;  Saund, 
1988.) 

4.3  Biological  Support 

Our  fine-to-coarae  proposal  runs  counter  to  current  trends  in  computer  and  ma¬ 
chine  vision.  Although  a  recent  study  by  Saund  (1988)  shows  how  the  grouping 
of  fine  scale  tokens  can  capture  coarse-scale  structure,  additional  supporting  ev¬ 
idence  for  this  unorthodox  approach  is  desirable.  Here  we  appeal  to  evidence 
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Figure  11  Small  maaka  would  be  expected  to  underlie  the  computation 
of  high  curv&tnrea  (A),  whereaa  larger  maaks  would  aeem  to  be  required  for 
computing  low  eurvaturea  (B). 

that  one  of  the  most  powerful  vision  processors — our  own — seems  to  use  this 
fine-to-coarse  strategy  [see  Richards  (1988)  for  a  stereo  example]. 

Recently,  Wilson  Sc  Richards  (1989)  estimated  the  size  of  curvature  operators 
using  a  discrimination  paradigm.  The  idea  is  quite  simple,  as  illustrated  in 
Figure  11.  For  high  curvatures,  small  oriented  edge  or  bar  masks  will  be  needed. 
For  lower  curvatures,  the  obvious  first  choice  is  to  simply  magnify  these  same 
operators.  Thus,  the  expectation  is  that  large  scale  (tangent)  masks  will  be  used 
for  low  curvatures,  whereas  fine  scale  (tenant)  masks  compute  high  curvature. 

Contrary  to  our  expectations,  fine  scale  masks  are  used  in  the  discrimina¬ 
tions  of  both  high  and  low  curvatures.  Coarse  masks  are  not  used  to  perform 
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discriminations  of  low  curvature.  This  conclusion  is  reached  from  two  observa¬ 
tions: 

(1)  Blurring  the  image  contour  greatly  impured  low  curvature  discrimination 
(as  well  as  high  curvature  discrimination) — contrary  to  what  one  would  ex¬ 
pect  if  larger,  coarser  masks  are  used  to  compute  low  curvatures. 

(2)  Band  limiting  low  curvature  contours  so  they  were  visible  only  to  the  finer 
channels  did  not  impair  curvature  discrimination — again  suggesting  that  the 
finer  scale  channels  were  responsible  for  the  low  curvature  discrimination. 

A  final,  important  result,  was  a  demonstration  that  the  fine  scale  (tangent)  oper¬ 
ators  were  capable  of  computing  low  curvature  provided  a  neighborhood  scheme 
was  used,  rather  than  local  differentiation  as  described  in  an  earlier  section.  This 
second  curvature  mechanism  is  described  below. 

4.4  Co*circularity  and  Curvature 

Consider  the  arc  illustrated  in  Figure  12,  with  local  coordinate  frames  at  points  A 
and  B  and  with  the  x  axis  set  by  the  tangent  to  the  contour.  Then  two  tangents 
Xa  and  Xh  are  defined  as  cocircular  if  and  only  if  there  is  a  circle  to  which  they 
are  both  tangent.  Note  that  by  this  definition  the  tangents  make  equal  but 
opposite  angles  ^  to  the  line  joining  the  p>oints  of  tangency.  Thus  cocircularity 
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Figure  13  Locei  coordinate  framea  at  A,  B,  and  ff  satisfy  the  cocircniarity 
constraint  when  da  =  — d&>  (I^om  Koenderink  it  lUchards,  1988.) 

defines  a  symmetry  relation  between  the  tangents  and  relates  several  schemes 
for  recovering  shapes  or  their  developmental  processes  (Blum,  1973, 1978;  Brady 
Asada,  1984;  Leyton,  1988).  Referring  to  Figure  12,  we  see  that  this  bilocal 
operator  for  curvature  can  be  defined  by  the  amount  of  rotation  2d  of  the  local 
coordinate  frame  over  the  displacement  5,  namely  KeoeireU  =  2^/6.  Parent  it 
Zucker  (1987)  use  this  method  quite  successfully  to  infer  continuity  of  segments 
of  broken  lines  or  of  intersecting  contours.  It  also  appears  to  be  the  scheme  used 
by  the  human  visual  system  for  curvatures  below  10  deg~^,  according  to  the 
Wilson  it  Richards  data. 

The  advantages  of  this  second  curvature  mechanism  are  clear.  If  only  fine* 
scale  tangents  are  constructed  along  a  curve,  then  an  exceedingly  smaU  angular 
resolution  would  be  required  to  compute  curvature  from  adjacent  tangents  on  a 
curve.  However,  as  the  distance  between  the  two  tangents  increases,  the  angular 
resolution  required  decreases. 

A  further  advantage  of  two  curvature  mechanisnu  is  that  each  really  ad* 
dreeees  a  different  problem.  Significant  part  boundaries  usually  create  acute 
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curvature  extrema,  auch  aa  “coruera” .  The  local  differentiation  operator  (or  its 
2D  equivalent)  ia  ideally  auited  for  this  task,  and  could  easily  appear  as  a  par¬ 
allel  computation  throughout  a  (foveal)  region.  The  bilocal  or  low  curvature, 
co-circular  mechanism  requires  more  machinery.  It  is  moat  useful  for  testing  for 
curve  or  contour  continuity,  either  when  two  curves  intersect  or  when  a  contour 
is  broken.  Generally  these  are  low  curvature  computations  that  need  to  take 
place  at  points  where  high  curvature  ia  present,  such  as  at  the  intersection  of 
two  curves  where  “comers’*  are  created,  or  at  “T”  junctions.  Thus,  a  parallel 
set  of  high  curvature  operators  could  identify  regions  where  the  more  complex 
machinery  of  co-circularity  could  be  profitably  applied. 

5.0  Inferring  3D  Curvature 

We  now  have  an  image-based  data  structure  that  describes  a  silhouette  or  image 
curve  in  terms  of  curvature  extrema  or  magnitude.  Our  next  task  is  to  infer 
the  3D  shape  from  the  2D  image  contour.  As  illustrated  in  Figure  13,  our 
implementation  takes  in  an  image,  identifies  blobs,  and  then  calculates  the  2D 
shape  of  the  blobs  in  terms  of  a  sequence  of  codons  (upper  right).  The  data  can 
be  presented  either  as  a  string  of  curvature  versus  edge  position  as  in  Figure  10, 
or  pictorially  for  use  in  alignment  schemes  as  in  Figure  13.  Here,  Snoopy’s  head 
has  been  given  symbollic  codon  labels  (!'*',  1~ ,  2)  that  represent  a  description  of 
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Figure  IS  Codon  l&beUng  for  Snoopf's  head,  shown  u  n  blob  in  the  upper 
left-hand  panel  at  one  scale  of  a  binary  pyramid.  Lower  left,  tangent  angle 
versus  position  along  the  contour;  lower  right,  coarsest  scale  of  the  curva¬ 
ture  space,  showing  marked  curvature  extrema;  upper  right,  resultant  codon 
labeling. 


this  shape  at  one  scale  of  the  curvature  computation.  As  previously  mentioned, 
a  sequence  of  codons  provides  a  complete  description  of  a  curve  in  terms  of  very 
primitive  elements  defined  by  singularities  of  curvature  (i.e.  maxima,  minima, 
and  seros).  Because  the  set  is  complete  at  this  level  of  description,  we  can  use 
the  codons  to  enumerate  all  possible  silhouettes  that  we  may  encounter  in  our 
images.  Because  of  constraints  on  joining  sequences  of  codons,  there  are  only  21 
possible  shapes  of  smooth  objects  having  four  or  less  codons.  Some  of  these  are 
shown  in  Figure  14.  These  shapes  wiU  serve  as  our  set  of  2D  "silhouettes”  whose 
8D  structure  we  wish  to  recover.  They  represent  the  classes  of  topologically 
different  outlines  that  can  be  constructed  from  up  to  four  smooth  closed  codon 


Figure  14  Different  claesea  of  the  ontiinee  to  be  interpreted.  Daahed  lines 
are  the  preferred  flexional  (parabolic)  loci.  Primee  indicate  altemative  inter¬ 
pretations. 

strings.  Although  this  set  may  appear  limited,  it  is  easily  extended.  It  will 
become  clear  that  our  interpretation  method  will  still  handle  the  extended  set. 

5.1  Choosing  a  SD  Representation 

To  begin,  we  need  a  means  of  describing  the  shape  of  a  SD  surface — its  undula¬ 
tions,  protrusions,  folds,  etc.  We  choose  for  this  purpose  an  intrinsic  property  of 
8D  surfaces,  namely  Gaussian  curvature. 

At  any  point  on  a  smooth  (non-planar)  surface,  there  is  a  direction  where  the 


surface  curves  the  most  and  another  where  the  surface  curves  the  least.  These 
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two  directions  are  the  directions  of  principal  curvature,  and  they  are  always 
perpendicular  (Hilbert  Si  Cohn-Voesen,  1952).  The  Gaussian  curvature  is  simply 
the  product  of  the  (signed)  magnitude  of  these  two  curvatures.  Of  particular 
interest  to  us  here  is  simply  the  sign  of  the  Gaussian  curvature,  which  permits 
a  .qualitative  description  of  the  topology  of  the  surface  in  terms  of  four  basic 
types  of  "parts”:  an  ellipse,  a  saddle,  a  cylinder,  or  a  plane.  If  the  signs  of  both 
principal  curvatures  are  identical,  the  surface  patch  is  elliptical  and  the  Gaussian 
curvature  is  positive;  when  the  principal  curvatures  have  opposite  signs,  the 
region  is  a  "saddle”  and  the  Gaussian  curvature  is  negative  (see  Figure  15).  A 
cylinder  has  one  principal  curvature  equal  to  zero;  for  the  plane  all  curvatures 
are  zero  and  in  both  these  cases  the  Gaussian  curvature  is  therefore  also  zero. 
An  ellipse  may  now  be  represented  as  a  3D  surface  everywhere  having  positive 
Gaussian  curvature.  (Our  scheme  will  thus  not  distinguish  between  an  ellipse 
and  other  totally  convex  shapes,  such  as  an  ovoid.)  A  3D  dumbbell  would  be 
described  as  two  elliptical  protrusions  of  positive  Gaussian  curvature  joined  by  a 
hyperbolic  region  of  negative  Gaussian  curvature.  A  3D  peanut  is  a  hyperbolic 
region  lying  within  an  ellipsoid  of  positive  Gaussian  curvature.  Note  that  our 
description  of  3D  shapes  in  terms  of  Gaussian  curvature  captures  only  the  general 
topology  of  the  shape.  Hence  a  dumbbell  and  a  pear-shaped  object  have  similar 
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K>0  K<0 

Elliptical  Hyperbollic 


K  =  0 
Cylindrical 


K  =  0 
Planar 


Figure  16  The  b&sic  types  of  surfaces  which  will  be  used  to  describe  3D 
shapes. 


descriptions.  To  capture  these  distinctions,  metric  information  can  be  added  at 
a  later  stage. 


5.2  Inferring  Gaussian  Curvature  from  Silhouettes 

Consider  now  the  pear-shaped  silhouette  of  Figure  14.  Our  3D  interpretation 
is  also  that  of  a  pear — as  if  this  silhouette  were  simply  a  surface  of  revolution. 
Why  is  such  an  inference  justified? 

A  3D  pear  is  simply  two  elliptical  protrusions  joined  by  a  hyperbolic  saddle. 
The  silhouette  gives  us  this  information  because  of  the  following  theorem  proved 
by  Koenderink  ii  van  Doom  (1982): 

Cl:  The  sign  of  Gaussian  curvature  of  points  on  the  3D  surface  that  project 
into  the  silhouette  is  the  same  as  the  sign  of  curvature  of  those  projections. 

This  theorem  assures  us  that  the  Gaussian  curvature  of  the  3D  shape  is  posi¬ 
tive  at  points  on  the  surface  that  project  into  regions  of  positive  curvature  on 
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the  silhouette.  Hence  the  elliptical  outline  is  the  projection  of  at  least  a  3D 
elliptical  "ribbon” .  Similarly,  both  the  peanut  and  pear  (or  dumbbell)  outlines 
of  Figure  14  require  that  the  corresponding  3D  shapes  have  hyperbolic  (sad¬ 
dle)  regions  of  negative  Gaussian  curvature  within  a  region  (or  two)  of  positive 
Gaussian  curvature.  Note  that  this  theorem  also  implies  that  dents,  which  have 
positive  Gaussian  curvature  but  are  concavities  in  the  surface  will  never  appear 
in  "generic”  silhouettes. 

At  this  point,  one  might  be  misled  to  the  false  conclusion  that  our  problem  of 
inferring  the  general  topology  of  3D  shapes  from  silhouettes  is  solved.  However, 
what  about  the  back  side  of  the  silhouette?  In  principle,  an  infinity  of  possible 
bumps  and  dents  could  occur,  leaving  open  unlimited  possibilities  for  the  "real” 
3D  shape.  Clearly  our  preferred,  immediate  3D  interpretation  has  assumed  that 
our  view  is  such  that  more  of  the  bumps  or  dents  of  the  object  are  occluded  or 
invisible.  In  other  words  all  the  "part”  structure  of  the  object  is  visible.  To 
capture  this  motion,  we  propose  the  following  interpretation  rule: 

C2:  Do  not  propose  undulations  of  the  3D  surface  without  evidence  for 

such. 

The  above  rule  is  an  extension  of  the  general  position  restriction,  which  requires 
that  the  view  of  an  object  is  not  a  special  one  and  is  stable  under  perturbation. 
Further  evidence  supporting  this  interpretation  rule  has  recently  been  provided 
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by  Warrington  (1986),  who  shows  that  the  appearance  of  “part”  structure  in  a 
silhouette  is  critical  to  recognition;  additional  parts  are  not  inferred  until  they 
become  visible  in  the  silhouette. 

Surprisingly,  even  with  the  two  above  constraints  we  still  can  not  force  a 
unique  3D  description  (in  terms  of  allowable  undulations  and  protrusions).  Con¬ 
sider  shape  Q7.  Is  this  shape  a  torso  with  two  “bumps”  on  top,  or  is  it  a  dumbbell 
with  a  furrow'shaped  saddle  in  one  end?  To  characterize  these  differences  more 
clearly,  we  can  enclose  the  regions  of  pontive  (and  negative)  Gaussian  curvature 
as  illustrated  by  the  dashed  lines  in  Figure  14.  These  lines  which  separate  the 
regions  of  positive  and  negative  curvature  obviously  must  have  zero  Gaussian 
curvature — ^they  are  locally  cylindrical  patches.  Clearly  these  lines  of  zero  Gaus¬ 
sian  curvature — the  so-called  flexional  or  parabolic  lines — must  go  through  the 
inflection  points  on  the  silhouette.  Again,  Koenderink  Sc  van  Doom  (1987)  have 
proven  an  important  theorem  about  the  behavior  of  these  lines: 

C3:  For  smooth  generic  surfaces,  the  flexional  parabolic  lines  of  zero  Gaus¬ 
sian  curvature  are  closed  and  non-intersecting. 

Thus,  for  a  simple  pear-shaped  object  with  four  inflexions  on  the  silhouette,  we 
are  allowed  only  two  3D  decompositions  as  illustrated  in  Figure  16.  Generally, 
as  proven  by  Beusmans  et  al.  (1987),  there  will  be  [„”3]/(n/2  4-  1)  possible 
legal  generic  interpretations  of  a  silhouette  having  N  inflections.  Thus  shape  Q7 
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Figure  10  (a)  A  contoar  having  four  inflection  points  (Ji,  I2,  h,  I4).  The 
corresponding  four  parabolic  points  (Pi,  P2,  Pi,  P4)  on  the  fold  can  be  paired 
generically  (b),  (c)  or  nongenerically  (d).  (From  Bensmaas  et  al.,  1987.) 

has  14  possible  legal  decompositions,  yet  only  the  two  shown  in  Figure  14  are 
readily  visualized.  This  suggests  further  constraints  or  assumptions  are  imposed 
upon  our  interpretations  of  silhouettes.  As  discussed  elsewhere,  one  of  the  key 
interpretation  rules  appears  to  be  an  extension  of  the  general  position  rule  (C2) 
mentioned  earlier: 

C4:  Without  evidence  to  the  contrary,  pick  the  most  general  position  3D 
interpretation,  namely  that  3D  shape  which  preserves  the  signs  of  Gaussian 
curvature  of  the  silhouette  over  the  widest  range  of  viewpoints. 
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This  rule  favors  surfaces  of  revolution,  and  excludes  local  furrows  (saddles)  when* 
ever  possible.  Thus,  the  preferred  interpretation  for  the  dumbbell  or  pear-shaped 
object  is  just  that,  and  not  something  created  by  two  separate  saddle-shaped  fur¬ 
rows.  This  rule  reduces  the  preferred  interpretations  of  our  given  initial  set  of 
topologically  different  shapes  shown  in  Figure  14  to  those  illustrated.  Thus,  for 
any  given  2D  image  silhouette,  we  obtun  a  very  restricted  set  of  preferred  3D 
interpretations  from  the  infinity  of  possibilities. 

6.0  Parts,  Processes  and  Perceivers 

Now  consider  the  amoeba-like  shape  shown  in  Figure  17.  Although  we  have  rules 
for  describing  this  silhouette  as  a  3D  shape  in  terms  of  regions  of  positive  and 
negative  Gaussian  curvature,  a  more  desirable  description  would  be  in  terms  of  a 
part-based  structure.  After  all  — ^we  don’t  describe  a  human  body  as  a  collection 
of  elliptical  and  hyperbolic  patches,  but  rather  as  a  torso  with  a  head,  neck, 
arms,  legs,  etc.  How  can  we  convert  a  description  based  on  Gaussian  curvature 
into  the  more  useful  part-based  representation?  Clearly  we  know  where  the  part 
boundaries  are — these  are  the  extrema  of  negative  curvature.  But  given  one 
such  concavity,  to  which  should  it  be  pured?  We  wiU  consider  two  approaches 
to  this  problem:  (1)  the  process-history  description  (Leyton,  1988)  and  (2)  the 
Gaussian  curvature  description  (Richards,  Koenderink  Se  Hoffman,  1987).  Each 
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A 

Fignre  17  Point  P  is  n  part-bonnd&iy,  being  nn  extremum  of  negative 
curvature.  To  vrhicb  other  extremum  should  the  boupdaty  be  paired? 

method  produces  fourteen  different  part-based  descriptions  of  this  simple  amoe¬ 
boid  shape.  A  few  of  each  are  illustrated  in  Figure  18.  The  problem  is  to  find  a 
set  of  rules  which  will  pick  out  the  preferred  interpretations. 

A  m^or  step  in  solving  this  type  of  problem  has  been  made  recently  by 
Jepson  ii  Richards  (1989).  The  advance  was  showing  that  a  perception  can  be 
regarded  as  an  interpretation  associated  with  a  locally  maximal  node  in  a  lattice 
of  possible  interpretatioxu  of  the  sense  data.  To  construct  such  a  lattice,  it  is 
necessary  to  invoke  models  of  the  world  which  are  not  always  correct.  Gener¬ 
ally,  one  or  more  of  the  model  elements  must  be  given  up  or  ‘faulted”  when 
constructing  a  possible  interpretation. 

For  example,  the  possible  interpretations  of  the  amoeboid  shape  shown  in 
Figure  18  may  be  ordered  by  preferring  shapes  which  satisfy  the  following: 
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Figure  18  PoMible  part-baaed  daacriptioBf  for  aa  amoeboid  ehape  luing 
axlatbaaed  decompoettioa  (left)  or  one  baaed  on  Gavaaiaa  cnrratnie  (right). 
The  treea  at  the  left  and  right  marghiB  enggaat  the  proceaa  hiatory. 
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GAUSSIAN  CURVATURE 


Figure  19  A  p&rti&l  ordering  of  part-baeed  interpretations  for  an  amoeboid 
shape,  nsing  Ganssian  cnrvatnre  primitives.  Model  premises  B,  P,  H,  G  are 
l^ven  in  the  text.  The  highest  node  in  the  lattice  {BPHG)  requires  giving 
up  (or  faulting]  none  of  the  preferred  models.  There  is  also  another  maximal 
node  (BPHG)  which  &ulta  one  model  premise  (B). 


B:  The  Object  Body  in  the  largest  part. 

P:  Parts  are  convex. 

H:  Parts  are  separated  by  hyperbollic  regions. 

G:  The  Body  contains  the  center  of  maw. 


A  portion  of  the  resultant  lattice  for  interpretations  based  on  Gauwian  cur¬ 
vature  is  shown  in  Figure  19.  There  are  two  locally  maximal  nodes  (BPHG)  and 
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{BPHG).  These  interpretations  correspond  respectively  to  an  ovoid  with  two 
symmetric  protrusions  (BPHG)  and  a  hyperbolic  body  with  four  protrustions 
(SpHG).  As  indicated  by  the  bar,  one  rule  was  violated  for  the  latter  inter¬ 
pretation.  But  still  more  violations  would  have  occured  if  other  submaximal 
interpretations  were  accepted,  as  indicated  by  the  superscripts.  Similarly,  the 
process-based  descriptions  can  be  given  a  partial  ordering  using  slightly  different 
rules  which  apply  to  axes.  This  lattice  is  different  from  that  shown  in  Figure  19, 
although  one  of  the  locally  maximal  nodes  is  identical  to  BPHG,  and  hence 
would  yield  a  perception  with  the  same  part-based  description.  Additional  psy¬ 
chophysical  studies  of  lattices  based  on  different  representations  are  in  progress. 

Finally,  we  now  have  some  insight  into  how  to  proceed  in  our  analysis  of  oc¬ 
cluded  shapes.  If  our  interpretation  rules  are  context-sensitive — as  they  should 
be — then  the  structure  of  our  lattice  of  interpretations  can  be  drastically  altered 
by  neighboring  structures  (in  space  or  time).  Thus,  in  Figure  20A  the  context 
suggests  "disc-like”  models,  and  the  occluded  shapes  are  so  interpreted.  But  in 
the  presence  of  a  "peanut”  world  (Figure  20B),  the  occluded  shape  is  now  more 
readily  seen  as  a  peanut.  Similarly,  if  texture  is  added  to  one  of  the  occluded 
halves,  but  not  the  other,  then  the  percept  that  there  is  only  one  object  would 
require  violating  the  notion  that  an  object  should  be  uniformly  colored  and  tex¬ 
tured.  Hence  two  different  objects  will  be  inferred.  The  "Perceiver  FVamework” 
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Figure  30  In  wiadotr  (A),  the  pok  eppeen  to  ocelnde  two  aepente  dkcs. 
However,  in  window  (B),  n  lingie  dninbbeil-Bhnped  object  Menu  more  likely. 

is  a  vehicle  for  making  such  inferences  quite  rigorous,  and  is  likely  to  drive  a 
good  portion  of  our  future  research. 

7.0  Summary 

We  have  roamed  over  a  rather  broad  territory  in  order  to  illustrate  the  advan¬ 
tages  and  difficulties  encountered  in  using  curvature  as  a  basis  for  inferring  the 
structure  of  smooth  3D  shapes.  Thanks  to  several  implementations,  we  know 
that  the  c<»nputation  of  image  curvature  is  feasible.  Given  this  2D  description, 
assigning  3D  Gaussian  curvature  is  strughtforward.  The  difficulty  is  that  at 
present  our  programs  are  not  powerful  enough  to  choose  among  the  possible  3D 
interpretations,  especially  in  the  presence  of  occlusions.  Recent  work  on  fault 
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lattices  offers  one  promising  approach,  however.  Again,  we  expect  to  rely  heav¬ 
ily  upon  hints  from  human  vision  to  guide  us  in  how  the  3D  shape  interpretations 
might  be  made  from  2D  image  contours,  or  silhouettes.  An  important  step  would 
be  to  embody  these  newer  ideas  in  a  working  machine  program,  just  as  has  been 
done  for  the  computation  of  image  curvature.  Another  would  be  to  extend  the 
analysis  from  smooth  objects  to  include  those  with  fractal-like  structures. 
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2.3  How  to  Make  TOOLKIT 

2.4  The  Euviromuent 

2.5  Graphics  Windows 

2.6  Terminal  Screen  Windows 

2.7  Menus 

2.7.1  Menu  Descriptors 

2.7.2  Menu  Entries 

2.8  Commands 

2.8.1  Switches 

2.8.2  Arguments 

2.8.3  Data  Table 

2.8.4  Argument  Values 

2.8.5  How  Data  Tables  Are  Installed 


2.9  Adding  a  Menu  to  TOOLKIT 

2.10  Adding  a  Command  to  TOOLKIT 

2.10.1  Adding  a  Command  to  a  Menu 

2.10.2  Creating  <command>.c 

2.10.3  Modifying  a  Command  to  Run  on  the  BMP  Processor 

2.11  Useful  Support  Routines 

3  TOOLKIT  Commands 


Add  Title 
Appodize 
Bandpass  Filter 
Binarize 
Block  FiU 
Change  Directory 
Circle 

Clear  Window 
Color  Threshold 
Complement 
Convert  Types 
Copy  Window 
Delete  Tsave 
Delete  Window 
Demo  Lambert 
DoG  Filter 


Enhance  Contrast 
FFT  Image 
FFT  Plot 
Fourier  Fractal  Seg 
Gaussian  Expand 
Gaussian  Filter 
Gaussian  Reduce 
Get  ID 
Get  Picture 
Grey  Operations 
Grid 
Halftone 
Help 

Histogram 
Info  Window 
Init  Display 
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Integer  Operations 
Interpolative  Zoom 
Line  Segment 
List  Windows 
Make  ID  FVactal 
Make  2D  Fractal 
Make  Window 
Median  Filter 
Mouse  Block  Fill 
Mouse  Block  Read 
Mouse  Dots 

Mouse  Drag  New  Window 
Mouse  Jagged  Line 
Mouse  Make  Window 
Mouse  Pixel  Read 
Mouse  Polygon 
Mouse  Seeded  fill 
Mouse  Spline 
Mouse  Straight  Line 
OH  Curve 
Print  Picture 
Put  Picture 
Quit 

Random  Binary  Image 
Rectangle 
Refresh  Terminal 
Replace  Color 


Replicative  Zoom 
Rotate  90 
Run  Script 
Scale  Pixels 
Script  Off 
Script  On 
Set  Env 
Show  Env 
Show  Title 
Snap  Picture 
Statistics 

Subsampling  Reduce 

Superimpose 

Text 

Thin 

Threshold 

To  Core 

To  Screen 

IVanslate  Pixels 

TVestore 

TVim 

Tsave 

Verify  Fractal 
Wedge 
White  Noise 
Zero  Crossings 
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1.  User's  Guide  to  TOOLKIT 

1.1  Introduction 

This  guide  describes  the  purpose  of  TOOLKIT,  the  concepts  needed  to 
understand  its  operation,  and  the  conmands  needed  to  use  it. 

TOOLKIT  was  developed  by: 

Benjamin  M.  Dawson  and  Peter  W.  Hallinan 
ElO  -  120 

Dept  of  Brain  and  Cognitive  Science 
Massachusetts  Institute  of  Technology 
Cambridge,  MA  02139 

Work  on  TOOLKIT  was  supported  in  part  by  AFOSR  contract  F  49620-83-C- 
0135. 

TOOLKIT  is  designed  to  facilitate  the  application  of  image  processing 
routines  to  color,  binary,  and  greyscale  images.  Simple  graphics  rou¬ 
tines  are  also  included  to  allow  both  the  construction  of  artificial  im¬ 
ages  having  a  particular  intensity  function  (e.g.  perfect  ramp  edges) 
and  the  modification  of  real  images. 

TOOLKIT  is  motivated  by  four  goals: 

1)  To  provide  an  interactive  interface  usable  by  both  beginners  and  ex¬ 
perts  . 

2)  To  exploit  the  variety  of  hardware  -  graphics  printers,  mice,  graph¬ 
ics  displays,  and  video  cameras  -  available  to  the  Natural  Computation 
Group  using  device-independent  code. 

3)  To  consolidate  existing  programs  into  an  easily  usable  whole  and  pro¬ 
vide  a  structure  to  which  future  programs  can  be  easily  added. 

4)  To  provide  a  turnkey  demonstration  system. 


1.1.1  Required  Hardware 

This  version  of  TOOLKIT  requires  a  VT-100  terminal  or  VT-100  compatible 
terminal  (for  split-screen  operation) .  If  you  attempt  to  run  this  ver¬ 
sion  of  TOOLKIT  on  another  kind  of  terminal,  you  will  see  junk  on  the 
screen.  Other  versions  of  TOOLKIT  run  under  windowing  systems  on  works¬ 
tations  such  as  the  SUN. 

TOOLKIT  can  be  used  without  a  display  device,  although  not  being  able  to 
see  the  images  and  results  makes  using  it  difficult.  If  a  display  dev¬ 
ice  is  used,  it  must  have  at  least  8  bits  per  pixel,  and  preferably  24 
bits  per  pixel  (8  bits  each  for  red,  green,  and  blue) .  The  display  dev¬ 
ice  must  also  have  at  least  512  by  512  pixels,  not  all  of  which  need  be 
displayed. 

This  version  of  TOOLKIT  supports  the  Ikonas  (Adage)  3000  and  the  Raster 
Technologies  Model  one/25  for  image  display.  Images  can  be  acquired 
with  the  Ikonas,  or  from  disk  files.  It  is  a  fairly  easy  task  to  change 
TOOLKIT  to  support  other  image  display  and  acquisition  devices. 


1.2 


Entering  TOOLKIT 


At  the  Unix  prompt  type: 


A3 


toolkit  t-acei]  [script  files...] 

You  will  see  a  copyright  line  in  the  middle  of  the  screen  separating  a 
menu  window  at  the  top  from  an  interactive  window  at  the  bottom.  The 
TOOLKIT  prompt  >  appears  in  the  interactive  window  and  TOOLKIT  awaits 
your  command. 

1.2.1  Executable  Images 

This  version  of  TOOLKIT  exists  as  a  set  of  device  dependent  executables: 

/usr /menu /SRC /ms_iknew 
/usr/menu/SRC/ms_srt 

for  the  Ikonas  (Adage)  3000  and  the  Raster  Technologies  model  one/25. 

A  UNIX  C  Shell  script  file: 

/usr/local/toolkit 

selects  the  correct  executable  depending  on  C  shell  environment  vari¬ 
ables  that  are  set  at  login.  These  variables  name  the  printers,  point¬ 
ing  devices  (e.g.  mice),  and  display  devices  that  are  closest  (in  space) 
to  the  terminal  logged  into.  Thus  for  a  user  sitting  next  to  a  display 
connected  to  the  Ikonas,  TOOLKIT  will  invoke  the  image  compiled  with  the 
Ikonas  specific  routines. 

1.2.2  The  C  Shell  Environment 

The  following  variables  should  be  set  before  calling  TOOLKIT: 

ROOM 

PRINTER 

GPRINTER 

DISPLAY 

POINTER_TYPE 

POINTER_IO 

They  can  be  set  by  hand  or  the  following  commands  may  be  placed  in  your 
.login  file: 

setenv  ROOM  'gethardware  room' 

setenv  PRINTER  'gethardware  printer' 

setenv  GPRINTER  'gethardware  gprinter' 

setenv  DISPLAY  'gethardware  display' 

setenv  POINTER_TYPE  'gethardware  pointer_type ' 

setenv  POINTER_IO  'gethardware  pointer_io' 

gethardware  is  a  program  that  accesses  the  database  /etc/hardware  to 
find  the  value  of  the  key  (e.g.  room)  passed  to  it. 

1.2.3  TOOLKIT  Switches 

Four  switches  may  be  specified  on  the  UNIX  command  line  in  order  to  tell 
TOOLKIT  to: 

a  abort  if  an  error  occurs  while  executing  a  script  file  argument, 

c  create  all  image  windows  in  core  because  you  will  not  be 
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using  a  graphics  display. 

e  echo  to  the  terminal  screen  command  lines  found  in  script 

files  passed  as  arguments. 

i  initialize  the  graphics  display  upon  starting  TOOLKIT. 

The  -i  and  -c  switches  are  mutually  exclusive. 

Switches  must  be  prefixed  by  a  minus  sign  unless  two  or  more  switches 
are  concatenated  together,  in  which  case  only  the  first  need  be  prefixed 
by  -.  The  order  of  the  switches  with  respect  to  the  arguments  is  uncon¬ 
strained. 

1.2.4  TOOLKIT  Arguments 

You  may  specify  any  number  of  script  files  on  the  command  line  (up  to 
the  limits  imposed  by  UNIX) .  Wildcards  and  other  such  characters  are 
expanded  by  the  C  Shell  in  the  normal  fashion.  Thus: 

toolkit  *.s 

runs  all  script  files  suffixed  with  ".s"  in  the  working  directory. 

1.2.5  Startup  Script 

When  starting  up,  TOOLKIT  automatically  tries  to  run  the  script  file: 
tkinit . s 

TOOLKIT  first  looks  for  tkinit. s  in  the  current  working  directory.  If 
the  script  is  not  found,  then  TOOLKIT  looks  in  the  home  directory.  If 
tkinit. s  is  still  not  found,  TOOLKIT  goes  on  to  run  any  script  files 
passed  as  arguments. 

1.2.6  Initialization 

TOOLKIT  initializes  in  the  following  manner: 

1)  check  arguments  and  switches  for  validity 

2)  create  terminal  windows 

3)  instantiate  the  environment  variables 

4)  create  image  windows  (see  section  2.3  on  switch  -c) 

5)  open  the  display  device 

6)  initialize  the  display  device  if  -i  specified  (see  section  2.3) 

7)  execute  the  startup  script  file  tkinit. s 

8)  execute  any  script  files  passed  as  arguments 

9)  set  up  the  terminal  screen 

10)  start  Interactive  session 

To  repeat,  TOOLKIT  will  not  automatically  initialize  the  display  device, 
unless  you  issue  the  Snap  command  when  using  the  Ikonas  display,  in 
which  case  the  display  is  initialized  before  each  video  buffer  is 
grabbed . 

1.3  Exiting  TOOLKIT 

To  exit  TOOLKIT  permanently,  you  may: 

1)  type  "quit"  or  any  abbreviation  thereof,  or 

2)  type  Control-C 


Both  commands  restore  the  terminal  screen  to  normal,  close  any  open 
script  files,  and  exit. 

To  stop  TOOLKIT  temporarily  to  do  other  work  in  the  C  shell,  type 
Control-Z.  This  restores  the  terminal  screen  and  stops  the  TOOLKIT  pro¬ 
cess.  Upon  restarting  TOOLKIT,  you  may  use  the  command  Refresh  Terminal 
to  redisplay  the  menu  and  interactive  windows. 


1 . 4  Menus 

Menus  are  lists  of  commands  organized  hierarchically  by  function.  The 
current  menu  is  the  menu  displayed  in  the  top  half  of  the  terminal 
screen. 


There  are  two  special  menu  commands  displayed  in  every  menu: 

Main  Menu:  Forces  the  current  menu  to  be  the  topmost  (root)  menu. 

Up  Menu:  Forces  the  current  menu  to  be  the  parent  of  the  current  menu. 


To  set  the  current  menu  to  be  any  other  menu,  simply  type  the  name  of 
the  menu  at  the  TOOLKIT  prompt,  e.g.: 

>  System  Menu 

Typing  ?  or  ??  at  the  TOOLKIT  prompt  will  cause  a  one  line  description 
of  the  current  menu  to  be  printed  on  the  screen. 

Typing  the  name  of  a  menu  followed  by  a  :?  or  :??  will  cause  a  one  line 
description  of  the  requested  action  to  be  printed  on  the  screen. 

1.5  Image  Windows 

TOOLKIT  manipulates  image  windows  (two  dimensional  pixel  regions) .  Win¬ 
dows  can  be  located  in  core  memory  or  on  a  graphics  display.  Windows 
located  in  core  memory  DO  NOT  share  pixel  regions  even  if  their  posi¬ 
tions  and  sizes  indicate  they  overlap.  Windows  located  on  a  graphics 
display  DO  share  pixel  regions  if  they  overlap.  Thus  clearing  a  graph¬ 
ics  display  window  that  overlaps  a  second  window  will  result  in  the 
second  window  being  (partially)  cleared  as  well. 

The  top  left  corner  of  both  the  screen  and  a  window  is  numbered  (0,0) . 
Windows  have  six  attributes  of  concern  to  the  user: 


1) 

2) 

3) 

4) 

5) 

6) 
7) 


X  position  - 

y  position  - 

dx 

dy 

updated 

tsaved 

title 


X  location  of  top  left  corner  of  window  in  screen 
coordinates.  Unused  but  still  specified  for  core  windows, 
y  location  of  top  left  corner  of  window  in  screen 
coordinates.  Unused  but  still  specified  for  core  windows, 
width  of  window  in  pixels, 
height  of  window  in  pixels. 

specifies  whether  the  window  is  updated  in  core  or  on 
the  screen. 

specifies  (for  a  window  updated  on  screen)  if  the  window 
has  been  temporarily  saved  in  core  (a  kind  of  temporary 
backup) . 

a  string  associated  with  the  window.  It  can  be  displayed 
only  by  explicit  command. 
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When  TOOLKIT  is  run  using  a  graphics  device,  the  following  windows  are 
automatically  created  at  initialization  time: 


Name 

X 

Y 

DX 

DY 

Type 

Updated 

Tsaved? 

gO 

0 

0 

512 

512 

Grey 

on 

screen 

no 

gi 

0 

0 

256 

256 

Grey 

on 

screen 

no 

g2 

256 

0 

256 

256 

Grey 

on 

screen 

no 

g3 

0 

256 

256 

256 

Grey 

on 

screen 

no 

g4 

256 

256 

256 

256 

Grey 

on 

screen 

no 

cO 

0 

0 

512 

512 

Color 

on 

screen 

no 

cl 

0 

0 

256 

256 

Color 

on 

screen 

no 

c2 

256 

0 

256 

256 

Color 

on 

screen 

no 

c3 

0 

256 

256 

256 

Color 

on 

screen 

no 

c4 

256 

256 

256 

256 

Color 

on 

screen 

no 

tv 

0 

0 

512 

480 

Grey 

on 

screen 

no 

When  TOOLKIT  is  run  without  an  image  display  device,  the  following  win¬ 
dows  are  automatically  created: 


Name 

X 

Y 

DX 

DY 

Type 

Updated 

Tsaved? 

gO 

0 

0 

512 

512 

Grey 

in  core 

— 

gi 

0 

0 

256 

256 

Grey 

in  core 

— 

g2 

256 

0 

256 

256 

Grey 

in  core 

— 

g3 

0 

256 

256 

256 

Grey 

in  core 

— 

g4 

256 

256 

256 

256 

Grey 

in  core 

— 

Any  of  the  above  windows  can  be  deleted;  they  are  not  special  in  any 
way . 

The  maximum  number  of  image  windows  is  50 . 

1.6  TOOLKIT  Commands 
1.6,1  How  to  issue  commands 

All  commands  are  presented  to  the  user  in  a  menu  format;  however,  any 
command  may  be  issued  from  any  menu.  Commands  may  be  abbreviated  as 
long  as  the  abbreviation  is  unique.  If  the  command  is  in  the  current 
menu,  then  the  abbreviation  only  has  to  be  unique  within  the  current 
menu  because  the  current  menu  is  always  searched  first.  If  the  command 
is  composed  of  more  than  one  word,  the  additional  words  can  be  omitted 
or  abbreviated  just  like  the  first  as  long  as  (a)  the  abbreviated  com¬ 
mand  remains  unique  and  (b)  word  abbreviations  are  separated  by  a  space 
The  case  in  which  the  command  is  entered  does  not  matter. 

For  example,  the  command: 

>  Mouse  Jagged  Line 
can  be  abbreviated  by: 

>  mouse  jagged 

>  m  jag  IINE 

>  m  j  1 

etc.  but  not  by: 

>  m  (not  unique  -  will  conflict  with  the  ubicpaitous 

MAIN  MENU  if  nothing  else) 
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>  mjl  (no  spaces  between  word  abbreviations) 

1.6.2  Command  Arguments 

Arguments  may  be  included  on  the  same  line  as  the  command  or  may  be 
prompted  for  (see  Argument  Prompting  below) .  Arguments  placed  on  the 
same  line  as  the  command  are  separated  from  the  command  by  a  colon;  this 
is  necessary  because  commands  may  be  made  up  of  more  than  one  word.  An 
example  command  line  is: 

>  Statistics:  window  name 


There  are  four  argument  types: 


1)  text 

2)  reals 

3)  integers 

4)  strings 


-  printing  characters  enclosed  in  quotes 

e.g.  "this  is  text  *(&)(&  1981498" 

-  real  numbers  identified  by  a  decimal  point 

e.g.  -844.4343,  3.,  .65 

-  e.g.  -43  (decimal),  Oxff  (hex),  067  (octal) 

-  an  alphanumeric  word  beginning  with  a  letter 

e.g.  windowl 


1.6.3  Argument  Prompting 

An  alternative  to  specifying  arguments  on  the  command  line  is  invo)ce  ar¬ 
gument  prompting  by  specifying  less  than  the  required  number  of  argu¬ 
ments.  For  example,  if  a  command  required  five  arguments  you  could 
specify  the  first  two  and  be  prompted  for  the  remaining  three  or  specify 
none  and  be  prompted  for  all,  e.g.  entering: 

>  Statistics 

would  result  in  the  prompt : 

Window? 

If  no  arguments  are  specified  a  colon  is  not  required. 

To  quit  a  command  while  being  prompted  for  arguments,  type  a  period  at 
the  prompt,  e.g.: 


Window?  . 

will  get  us  out  of  the  Statistics  command  we  invoiced  above. 

Argximent  prompting  is  also  invoked  when  an  argument  is  found  to  be  an 
illegal  type.  (If  the  argument  is  the  right  type  but  the  wrong  value, 
then  the  command  will  fail.)  All  subsecjuent  arguments  are  assumed  to  be 
incorrect  as  well  and  are  prompted  for. 

1.6.4  Command  Switches 

Switches  are  used  to  change  the  action  of  a  command,  in  contrast  to  ar¬ 
guments,  which  instantiate  variables  employed  in  the  command's  computa¬ 
tions.  Switches  are  always  single  letters  prefixed  by  minus  signs,  ex¬ 
cept  when  several  switches  are  concatenated  together,  e.g.: 

>  Histogram  :  -t 

>  Histogram  :  -t  -c 

>  Histogram  :  -tc 
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are  all  legal  ways  to  specify  switches. 

Once  argument  prompting  takes  control,  switches  cannot  be  specified! 
1.6.5  Multiple  Invocations 

A  command  can  be  invoked  several  times  at  once  by  specifying  enough  ar¬ 
guments  for  the  extra  invocations.  For  example: 

>  Delete  Window  :  gl  g2 

will  result  in  Delete  Window  being  executed  twice  since  it  normally 
takes  one  argument.  If  we  specified: 

>  Make  Window  :  windowl  0  0  256  256  g  window2 

Make  Window  would  also  be  executed  twice;  argument  prompting  would  take 
care  of  the  unspecified  four  remaining  arguments. 

1 . 7  Help 

The  manual  that  describes  the  available  commands  is  available  on  screen, 
as  are  brief  descriptions  of  a  commands  arguments  and  switches,  and 
brief  descriptions  of  particular  menus. 

Note  that  all  coordinates  asked  for  and  displayed  are  window  coordinates 
(NOT  screen  coordinates)  unless  otherwise  specified, 

1.7.1  Help  on  particular  menus 

If  the  menu  in  question  is  the  current  menu  (ie  displayed  at  the  top  of 
the  terminal  screen),  type  either  ?  or  ??  at  the  prompt  to  get  a  short 
one  line  message  describing  the  menu. 

1.7.2  Brief  help  on  a  particular  command 

For  a  brief  list  of  a  commands  arguments  and  switches  enter  a  ?  at  the 
TOOLKIT  prompt  or  at  an  argument  prompt,  e.g.  either: 


or 


>  Histogram  :  ? 
Window  Name?  ? 


would  display  the  following  lines: 

Histogram;  <source>  <t''destination>  <c&clip> 

Switches :  <c  -  clip  hi  freq>  <t  «  termin.:il  only> 

Source,  destination,  and  clip  are  the  arguments,  c  and  t  are  the 
switches.  The  switches  modify  the  provision  of  arguments  in  the  follow¬ 
ing  way: 

o  Source  is  not  affected  by  any  switch, 

o  Destination  is  only  provided  if  switch  t  IS  NOT  specified 
(t  xor  destination) , 

o  Clip  is  only  provided  if  switch  c  IS  specified  (c  and  clip) . 

Thus,  if  a  is  an  argument  and  s  is  a  switch: 

s^'a  means  s  and  a  are  mutually  exclusive. 
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s&a  means  s  and  a  are  inseparable 
Entering: 

>  Clear  Window  :  ? 

Would  display  the  following  lines: 

Clear  Window:  <window>  <b^r  [0]>  <b^g  [0]>  <b''b  [0]> 

;  Switches :  <b  =  black> 

A  bracketed  []  expression  following  an  argument  name  contains  the  de¬ 
fault  value. 

1.7.3  Verbose  help  on  particular  command 

For  verbose  help  that  includes  a  verbal  description  of  a  command,  its 
arguments,  and  its  switches,  type  ??  at  either  the  TOOLKIT  prompt  or  an 
argument  prompt ,  e . g . 


>  Make  Window:  ?? 
Window  Name?  ?? 


1.8  Scripts 

Script  files  are  ascii  files  containing  a  series  of  command  lines. 

These  commands  should  appear  in  the  script  file  just  as  if  one  were  typ¬ 
ing  them  in  interactively. 


A  sample  script  file  might  look  as  follows: 


#  this  script 
Make  Window: 
Make  Window: 
Make  Window: 
Make  Window: 


file  builds  four  windows  @  128x128  pixels 
$  0  0  128  128  @ 

$  128  0  128  128  @ 

$  256  0  128  128  8 

$  384  0  128  128  @ 


The  $  is  used  to  specify  that  the  user  should  be  prompted  for  the 
corresponding  argument.  The  @  is  used  to  specify  that  the  corresponding 
argument  should  be  the  default  value.  Thus  this  script  will  prompt  for 
the  names  of  the  windows  and  assume  that  the  window  types  are  greyscale. 

Note  also  that  comment  lines  are  flagged  by  #. 

Scripts  can  be  passed  to  TOOLKIT  as  arguments  or  run  interactively.  If 
passed  as  arguments,  specifying  the  -e  switch  will  result  in  the  script 
file  name  and  individual  command  lines  being  written  to  the  screen. 

Also,  the  "more"  filter  used  by  TOOLKIT  to  seg.nent  large  tty  output  will 
not  be  enabled.  If  a  script  is  run  interactively  using  the  Run  Script 
command,  the  switch  -e  will  work  as  above  and  the  switch  -i  will  enable 
the  more  filter. 


Script  files  can  be  created  using  an  editor  or  they  can  be  created  dur¬ 
ing  an  Interactive  session  by  means  of  a  mechanism  that  records  success¬ 
fully  executed  commands.  The  recording  mechanism  is  turned  on  by  the 
Script  On  command  and  turned  off  by  the  Script  Off,  Quit  and  Control-C 
commands . 

If  a  script  file  contains  the  Quit  command,  TOOLKIT  will  exit. 

1 . 9  Environment 
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TOOLKIT  stores  device  paths  and  other  such  data  in  environment  variables 
local  to  TOOLKIT,  but  displayable  and  changeable  by  the  user. 

Current  environment  variables  and  sample  values  are: 


Terminal  Device 
Terminal  Type 
Printer 

Graphics  Printer 
Display 
Microcode 
Pointer  Type 
Pointer  Line 
Prompt 

Beep  On  Error 


=  /dev/tty 
=  vtlOO 
=  prO 
=  gr 

=  /dev/rsl 

•=  /usr/menu/MICROCODE/tk_bmplib  .u 
=  mouse 
=  /dev/tty05 
=  > 

=  On 


\ 


1.10  Shell  Commands 

*  j’ 

Shell  commands^  can  be  entered  either  at  the  TOOLKIT  prompt  or  at  an  ar¬ 
gument  prompt  by  prefacing  the  shell  command  with  the  shell  escape  char¬ 
acter  ! .  For  example,  you  could  obtain  a  directory  listing  before  or 
during  the  Get  Picture  command  by; 


>  !  Is  *.pic 

>  Get  Picture:  gO  rabbit. pic 

>  Get  Picture:  gO 
File  Name?  !ls  *.pic 
File  Name?  rabbit .pic 


If  script  recording  is  on,  shell  commands  issued  at  the  TOOLKIT  prompt 
will  be  recorded,  but  not  shell  commands  issed  at  the  argument  prompt. 


1,11  Summary  of  Special  Commands 

cmd  =  command 
a  =  arg\ament 
s  =  switch 
p  =  argument  prompt 
xyz  “  anything 
''  “  control 

Symbol  Usage  Importance 


:  cmd'.a  separates  a  command  from  its  arguments 

??  cmd;??  displays  lengthly  command-specific  help 

p;?? 

?  cmd:?  displays  short  list  of  arguments  and  switches 

p:? 

??  ??  displays  short  help  line  for  current  menu 

?  ?  displays  short  help  line  for  current  menu 

$  cmd;$  a  forces  prompting  for  a  specific  argument 

0  cmd:@  tells  routine  to  use  a  default  value  for  an  argument 

#  fxyz  precedes  comments 

!  !cmd  execute  cmd  in  the  shell  instead  of  toolkit 

p : ! cmd 

''C  ^C  causes  the  terminal  screen  to  be  restored  to  normal, 

closes  script  files,  exits  TOOLKIT 
''Z  ''Z  causes  the  terminal  screen  to  be  restored  to  normal, 

stops  TOOLKIT 
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1.12  Sample  TOOLKIT  session 


(The  TOOLKIT  program  starts  up  displaying  the  MAIN  MENU:) 

MAIN  MENU 


Help 

Quit 

Demo  Menu 


Graphics  Menu 
Mouse  Menu 
Peter' s  Menu 


System  Menu 
Transform  Menu 
Window  Menu 


Main  Menu 
Up  Menu 


=====•=========  TOOLKIT  Version  1.02,  (C>  Copyright  M.I.T.  1987  ============== 


>  tran 


(The  user  selects  the  Transform  Menu  (by  typing  tran) .  Incomplete  commands 
are  matched  and  completed.  A  session  using  the  Transform  Menu  follows.  It 
shows  the  use  of  detailed  help  (??),  help  with  arguments  (?) ,  and  argument 
completion  when  arguments  are  not  specified.  User  input  is  scrolled  below  the 
menu.  The  session  ends  with  a  Quit  command.) 


Binarize 
Complement 
DoG  Filter 
Enhance  Contrast 
Gaussian  Filter 
Grey  Operations 
Histogram 

==============  toolkit 


TRANSFORM  MENU 
Integer  Operations 
Interpolative  Zoom 
Median  Filter 
Replace  Color 
Replicative  Zoom 
Scale  Pixels 
Statistics 

Version  1.02,  (C)  Copyright 


Superimpose 

Thin 

Threshold 
Translate  Pixels 
Zero  Crossings 
Main  Menu 
Up  Menu 


M.I.T.  1987  ============== 


>  Repli  zo  :  ?? 

Replicative  Zoom:  <source>  <destination>  <x  zoom>  <y  2oom> 


REPLICATIVE  ZOOM: 


Source 
Destination 
X  Zoom 
Y  Zoom 


-  Does  a  replicative  integer  zoom.  The  source  window  is 
expanded  into  the  destination  window  by  replicating  pixels 
in  the  X  and  Y  directions.  If  the  destination  window  is 
too  big,  the  extra  area  is  untouched. 

-  May  be  greyscale  or  color. 

-  Must  be  the  same  type  of  window  as  the  source. 

-  Integer  scale  factor  (>  0)  for  horizontal  stretch. 

-  Integer  scale  factor  (>  0)  for  vertical  stretch. 


>  rep  zoom  :  gO  gl  2  2 


>  threshold  :  ? 

Threshold:  <window>  <lower  bound>  <upper  bound  > 
Switches:  <  b  -  function  b>  <c  -  function  c>  <s 

>  thresh  :  g2  40  100 


<color  or  grey  value> 
-  skip  color> 


>  scale 
Source?  gl 
Destination?  g2 
Scale  Factor  (real)?  .4 


>  zero  cr  :  ?? 

Zero  Crossings:  <source>  <destination> 

>  zer  cros  :  g2  gZ 


>  quit 
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2.  Programmer's  Guide  To  TOOLKIT 

2.1  Introduction 

This  section  describes  where  files  are  located,  how  to  make  TOOLKIT, 
what  the  data  structures  are,  how  to  add  and  modify  commands  and  menus, 
and  where  to  find  useful  subroutines  (e.g.  for  error  checking) . 


2.2 


2.3 


File  Locations 
/usr/etc 

/us r /menu /DEMO 
/usr/menu/DOC 

/usr/menu/INCLUDE 
/usr /menu /MICROCODE 
/usr/menu/OLDHIPS 

/usr/menu/SRC 


/usr /menu /SUBRS 
/usr /peter /RESEARCH 
How  to  Make  TOOLKIT 


C  shell  script  file  "toolkit"  used  to 
invoke  the  correct  device-dependent 
executable  file. 

Script  files  for  demo-ing  TOOLKIT 

Text  of  documentation  and  shell  script 
to  create  documentation  of  commands 

Include  files 

BMP  microcode  versions  of  commands 

old  version  hips  files  used  in  image 
file  10. 

source  and  object  for  the  infra¬ 
structure  —  e.g,  command  parsing, 
menu  tables,  etc  also  the  location  of 
the  executable  files. 

source  and  object  for  the  commands 
and  for  the  library  (support)  routines 

source  and  object  for  some  fractal 
related  commands . 


If  you  have  changed  an  include  file,  you  will  have  to  recompile  every¬ 
thing,  otherwise  you  can  just  go  to  the  directory  in  which  you  made  the 
change  and  type: 


make  all 

and  then  you  can  make  the  new  executables  by: 

cd  /usr/menu/SRC 
make  tk_rt  tk_ik 

The  only  directories  in  which  you  might  have  to  recompile  code  are: 

/usr/menu/MICROCODE 

/usr/menu/SRC 

/usr/menu/SUBRS 

Remember  that  if  you  change  a  filename  or  add  a  file  you  will  have  to 
modify  the  proper  Makefile  and  possibly  delete  the  old  version  of  the 
archive  library  so  that  no  multiple  declarations  occur. 
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2.4 


The  Environment 


The  environment 

is  a  global  structi 

which  are  loaded 
structure  is: 

1  from  various 

data 

typedef  struct  t 

_ENV  { 

char 

*  e_t  e  r m_de V ; 

/* 

char 

*  e_t  e  rm_t  ype ; 

/* 

char 

*e_printer/ 

/* 

char 

*e_gprinter; 

/* 

char 

*e_di splay; 

/* 

char 

*e_microcode; 

/* 

char 

*e__ptr_type; 

/* 

char 

*e_ptr_io; 

/* 

char 

*e_prompt ; 

/* 

bool 

}  ENV; 

e_beep; 

/* 

The  actual 


device  driver  for  terminal  */ 

terminal  type,  e.g.  vtlOO  */ 

printer  device  */ 

graphics  printer  */ 

display  driver  */ 

directory  containing  microcode  */ 

type  of  pointer  */ 

io  line  for  pointer,  eg  tty05  */ 

command  prompt  */ 

beep  on  error?  */ 


The  name  of  global  environment  is  "environment".  The  global  array 
"env_names"  contains  printable  strings  describing  each  variable.  If  the 
structure  is  modified,  then  routines  in  tk_env.c,  show_env.c,  and 
set  env.c  probably  will  have  to  be  changed  also. 


2.5  Graphics  Windows 

Graphics  windows  exist  on  the  display  device  or  in  core  if  there  is  no 
display  device.  The  structure  describing  a  window  is: 


typedef  struct  t_WIN  { 


int 

w_xs; 

/* 

int 

w_ys; 

/* 

int 

w_dx; 

/* 

int 

w_dy; 

/* 

char 

*w_name; 

/* 

int 

w_bpp; 

/* 

int 

w_type; 

!* 

int 

w_uf lags [NUF] ; 

/* 

char 

*w_title; 

/* 

int 

w_us; 

/* 

int 

*w_core; 

/* 

*WPTR/ 

X  start  -  pos  of  top  left  corner  */ 

y  start  -  pos  of  top  left  corner  */ 

X  width  in  pixels  */ 

y  width  in  pixels  */ 

ptr  to  symbolic  name  */ 
bytes  per  pixel  */ 
window  type  */ 
array  of  user  flags  */ 
title  string  */ 

value  of  update  screen?  predicate  */ 
ptr  to  core  space  for  image  - 
assigned  most  commonly  used  type  */ 


2 . 6  Terminal  Screen  Windows 

A  terminal  screen  window  is  defined  by  the  structure: 


typedef 

struct 

t_SCWINDOW  { 

int 

_maxy,  _maxx; 

/* 

int 

_begy,  _begx; 

/* 

bool 

_scroll; 

/* 

int 

_outcol; 

/* 

}  SCWINDOW; 

2.7 

Menus 

2.7.1 

Menu  Descriptors 

window  dimensions  */ 
absolute  pos  of  top  left  corner  */ 
value  of  can  it  scroll?  predicate  */ 
col  at  which  to  start  writing  */ 
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The  structure  describing  a  menu  to  be  displayed  on  a  terminal  screen  is: 


typedef 

Struct 

t_MENU  { 

char 

*title; 

/* 

char 

*helpline; 

/* 

int 

startx, starty; 

/* 

int 

ent ry count ; 

!* 

int 

nrows, ncols; 

/* 

int 

colsize; 

/* 

ENTRY 

*entry; 

/* 

}  MENU, 

*MENU_ 

POINTER; 

2.7.2 

Menu  Entries 

typedef 

struct 

t_ENTRY  { 

char 

*printname; 

/* 

int 

submenu; 

/* 

int 

(*f  binding)  ()  ; 

/* 

}  ENTRY, 

*ENTRY_POINTER; 

2 . 8  Commands 


Menu  title  */ 

Help  line  for  menu  */ 

Starting  x  and  y  */ 

Number  of  entries  in  menu  */ 
Number  of  rows  and  columns  *! 
Maximum  size  of  a  column  */ 
entries  for  this  menu  */ 


String  to  print  for  entry  */ 

Index  of  submenu.  -1  if  function  */ 
Function  binding  */ 


Commands  work  as  follows: 


1)  A  command  line  is  entered  interactively  or  by  script  file. 

2)  The  command  line  is  parsed  into  the  command,  switches  and  arguments. 

3)  The  command  is  matched  with  entries  in  the  menu  tables  until  a 
unique  match  is  found. 

4)  The  menu  entry  contains  a  ptr  to  a  function  that  when  invoked  re¬ 
turns  a  pointer  to  the  command  data  table. 

5)  The  switches  are  looked  up  in  the  commands  switch  table  to  see  a)  if 
they  are  legal  and  b)  if  they  change  the  number  of  arguments  the  command 
expects  (e.g.  sometimes  the  user  can  specify  a  switch  instead  of  a  par¬ 
ticular  set  of  three  color  arguments) . 

6)  the  number  and  type  of  arguments  are  compared  with  the  expected 
number  and  type  as  extracted  from  the  argument  table. 

7)  automatic  prompting  is  invoked  if  necessary  to  get  additional  un¬ 
specified  arguments  or  to  replace  arguments  that  have  an  illegal  type. 

8)  the  command  function  pointed  to  by  the  data  table  is  invoked  or  if 
help  is  requested  the  help  table  and  switch  info  are  printed. 

2.8.1  Switches 

Command  switches  are  contained  in  an  array  of  switch  descriptors.  Each 
descriptor  is  a  structure  of  the  form; 

typedef  struct  t_SDES  { 


char 

*s_name; 

/* 

name  of  switch  */ 

char 

s_val; 

/* 

value  of  switch  */ 

int 

s_adif f ; 

/* 

change  to  num  of  expected  args  */ 

int 

s  aindx; 

/* 

NOT  USED  */ 

}  SDES,  *SPTR; 


2.8.2 


Arguments 
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Command  arguments  are  contained  in  an  array  of  argument  descriptors. 
Each  descriptor  is  a  structure  of  the  form: 

typedef  struct  t_ADES  { 
char  *a_name; 

int  a_type; 

char  *a_def; 

}  ADES,  *APTR; 

2.8.3  Data  Table 

/*  structure  to  hold  information  about  a  ms  command 
*/ 


typedef 

Struct 

t_DATA  { 

int 

(*d_subr)  0 ; 

/* 

ptr  to  func.  that  performs  command  */ 

int 

d_argc ; 

/* 

number  of  args  */ 

ADES 

*d_ades; 

/* 

array  of  argument  descriptors  */ 

int 

d_switchc/ 

/* 

number  of  switches  */ 

SDES 

*d_sdes; 

/* 

array  of  switch  descriptors  */ 

char 

*d_use; 

/* 

short  help  line  */ 

int 

d_lines/ 

/* 

number  of  lines  in  long  help  */ 

}  DATA, 

char 

*DPTR; 

**d_help/ 

/* 

long  help  -  array  of  str  */ 

2.8.4 

Argument  Values 

/*  union  to  hold  an  argument  in  its  correct  data  format 
*/ 

typedef  union  t_AVAL  { 

int  v_int/  /*  integer  value  */ 

double  v_double/  /*  real  value  */ 

char  *v_str;  /*  str  value  */ 

}  AVAL,  *AVPTR; 

2.8.5  How  Data  Tables  Are  Instantiated 


/*  argument  prompt  */ 

/*  argument  type  */ 

/*  str  containing  default  value  */ 


In  each  file  containing  a  command,  the  programmer  explicitly  defines  an 
array  of  argument  descriptors,  an  array  of  switch  descriptors,  a  single 
string  that  constitutes  the  brief  help  line,  and  an  array  of  strings 
that  constitutes  the  long  help.  Finally,  the  programmer  calls  the  macro 
QUERY  with  the  name  of  the  data  table  and  the  name  of  the  subroutine 
that  he  wants  to  add.  QUERY  expands  into  the  following  routine  which 
defines  and  Instantiates  the  data  table.  The  ^able  is  local  to  the  file, 
as  are  all  the  other  data  structures.  If  the  programmer  defines  EXPEC- 
TARG  val,  then  val  is  the  number  of  arguments  ,the  command  will  expect  to 
receive  if  no  switches  are  given.  This  allows  the  programmer  to  specify 
more  argument  descriptors  in  the  table  than  are  usually  used.  Thus  a 
switch  s  can  be  defined  which  increases  the  number  of  expected  arguments 
whenever  it  is  specified.  Defining  EXPECTARG  is  not  necessary  to  create 
switches  that  decrease  the  number  of  expected  arguments. 


#define  SWITCHTAB 
fdeflne  ARGTAB 
fdefine  USAGE 
fdeflne  HELP 
fdefine  SIZES 
fdefine  SIZEA 
fdefine  SIZEH 


static  SDES  cmdsubr_s[] 
static  ADES  cmdsubraii 
static  char  *cmdsub’r_u 
static  char  *cmdsubr  h[] 

(sizeof (cmdsubr_s) /sTzeof (SDES) ) 
(sizeof (cmdsubr_a) /sizeof (ADES) ) 
(sizeof (cmdsubr  h) /sizeof (char  *)) 


/*  macro  defining  a  function  that  provides  access  to  a  routine's  data  table 
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*/ 

#ifdef  EXPECTARG 

#  define  QUERY (x,y)\ 

DPTR  x()\ 

{\ 

static  DATA  cmdsubr_d;\ 
extern  int  y();\ 
cmdsubr_d .  d_subr  >=  y;\ 
cmdsubr_d . d_argc  =  EXPECTARG; \ 
cmdsubr_d .  d_ades  =  cnidsubr_a;\ 
cmdsubr_d.d_use  =  cmdsubr_u;\ 
cmdsubr_d.d_lines  =  SIZEH;\ 
cmdsubr_d.d_help  =  cmdsubr_h; \ 
cmdsubr_d . d_sdes  =  cmdsubr_s ; \ 

cmdsubr_d.d_switchc  =  (cmdsubr_s [0] .s_val  ?  SIZES  :  0);\ 
return  <&cmdsubr_d) ; \ 

} 

#else 

#  define  QUERY (x,y)\ 

DPTR  x()  \ 

{\ 

static  DATA  cmdsubr_d/\ 
extern  int  y();\ 
cmdsubr_d.d_subr  =  y;\ 
cmdsubr_d.d_argc  =  SIZEA;\ 
cmdsubr__d.d_ades  =  cmdsubr_a;\ 
cmdsubr_d.d_use  =  cmdsubr_u/\ 
cmdsubr_d.d_lines  =  SIZEH;\ 
cmdsubr_d.d_help  *  cmdsubr_h; \ 
cmdsubr_d.d_sdes  =  cmdsubr_s/\ 

cindsubr_d.d_switchc  =  {cmdsubr_s  [ 0]  . s_val  ?  SIZES  :  0);\ 
return (&cmdsubr_d) ; \ 

} 

#endif 

2 . 9  Adding  a  Menu  to  TOOLKIT 

Files  to  Change:  /usr/menu/SRC/tk_menus . c 
Files  to  Add:  none 

1)  create  a  unique  #define  flag  for  the  menu. 

2)  create  a  menu  descriptor. 

3)  create  an  entry  list. 

4)  add  the  menu  name  to  the  menu  list. 

5)  add  a  command  to  the  parent  menu  to  access  the. 

new  menu  (this  command  will  require  the  fdefine  flag) . 

6)  do  not  forget  to  include  the  menu  commands-: 

MAIN  MENU 
UP  MENU 

in  the  new  entry  list. 

If  menu  descriptors,  entry  lists,  and  menu  lists  are  unfamiliar,  look  at 
other  menus  and  entry  lists  in  tk_menus.c  for  an  example,  and  consult 
section  4  for  a  description  of  the  structures  used. 

2.10  Adding  a  Command  to  TOOLKIT 

Files  to  Change:  /usr/menu/SRC/tk_menus.c 

/usr/menu/SUBRS/Makefile 
Files  to  Add:  /usr/menu/SUBRS/<command>. c 
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2.10.1  Adding  a  Command  to  a  Menu 

1)  Add  external  declaration  of  function  pointer  placed  in  the  entry. 

2)  Add  entry  to  the  appropriate  entry  list. 

For  example,  to  add  the  command  Histogram  to  the  Transform  Menu  we  add 
the  line: 

extern  int  histogramO; 

and  the  entry  {"Histogram",  FUN,  histogram}  to  the  entry  list: 

static  ENTRY  transform_entries []  = 

{ 

"Binarize",  FUN,  binarize, 

"Enhance  Contrast",  FUN,  enhance, 

"Gaussian  Filter",  FUN,  gaussian, 

"Histogram",  FUN,  histogram, 

"Interpolative  Zoom",  FUN,  int zoom, 

"Main  Menu",  MAIN_MENU,  goto_menu, 

"Up  Menu",  MAIN_MENU,  goto_previous, 

}; 


2.10.2  Creating  <command>.c 

Use  an  existing  command  file  (eg  histogram. c)  as  a  template.  If  the 
command  will  require  a  mouse,  use  m_bread.c  as  a  template. 

2.10.3  Modifying  a  Command  To  Run  on  the  BMP  Processor 

Files  to  Change:  /usr/menu/SUBRS/<command>.c 

/usr/menu/SUBRS/t}c_bmp.  c 
/usr/menu/SUBRS/xxx_bmp. c 
/usr/menu/SUBRS/xxx  host.c 
/usr/menu/MICROCODE7main . g 
/usr/menu/MICROCODE/Makef ile 
Files  to  Add:  /usr/menu/MICROCODE/<command>.g 

If  the  command  is  to  be  run  on  the  BMP  or  the  host,  then  use  copy.c  and 
copy.g  as  templates.  The  layer  of  indirection  exemplified  by  copy_xxx 
(see  copy.c)  serves  to  isolate  code  requiring  bmp  routines,  so  that  bmp 
code  is  contained  only  in  the  version  that  is  compiled  to  run  on  the 
BMP. 

2.11  Useful  Support  Routines 

The  following  files  contain  various  support  routines.  All  files  are  in 
/usr/menu/SUBRS . 

core_lib. c 
cs_rdhh . c 
cs_wthh. c 
drawbox . c 
drawcircle.c 
drawl ine.c 
fft  tj.c 
gsuEs .  c 
interact . c 
mouse . c 
pyramid. c 
readf ile . c 


read  and  write  pixels  to  core 
read  image  file  header 
write  image  file  header 
draw  a  box 
draw  a  circle 
draw  a  line 

compute  a  fast  fourier  transform 
gaussian  and  dog  convolution 
interactively  create  median  filter  kernel 
mouse  io 

move  and  down  multiresolution  pyramid 
read  file  into  window 
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solve_lib.c 
spline .c 
tk_bmp . c 
tk  rt,c 
utTl_lib.  c 

win_lib.c 

win_priin.  c 
writef ile .c 
xxx_bmp . c 
XXX  host.c 


solve  linear  matrix  equation  of  form  AX=B 
compute  spline 

c  interface  to  bmp  microcode  primitives 
c  interface  to  Rastech  primitives 
transfer  image  btwn  core  and  display, 
image  transforms 

window  manipulation,  error  checking,  assorted 
other 

read  &  write  pixels  -  top  layer 
write  image  to  file 

dispatch  to  bmp  or  host  depending  on  hardware 
dispatch  to  host  only 
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Add  Title:  <window>  <"title"> 


ADD  TITLE 


Window 

Title 


-  Adds  a  title  string  to  a  window's  internal  representation. 
Use  INFO  WINDOW  to  display  title  on  terminal  screen. 

Use  SHOW  TITLE  to  display  title  in  window. 

Call  this  routine  again  to  change  the  title. 

-  No  restriction. 

-  Limited  to  the  number  of  characters  that  will  fit  in  the 
window.  Title  must  be  contained  within  quotes. 

One  character  is  8  pixels  wide  and  10  pixels  high. 


Appodize:  <source>  <destination> 


APPODIZE 


Source 

Destination 


-  filter  image  with  ramp  edge  in  the  spatial  domain 

ramp  edge  defined  along  outermost  ten  pixels  of  shortest 
radius 

-  must  be  greyscale  with  square  dimensions  equal  to  power  of  2 

-  must  be  same  type  and  size  as  source 


Bandpass  Filter:  <source>  <destination>  <low>  <high> 
Switches:  <i  =  integer-valued> 


BANDPASS  FILTER 


Source 
Destination 
Low  Threshold 
High  Threshold 


delete  frequencies  below  a  low  threshold  and  above 

a  high  threshold.  This  filter  can  serve  as  a 

lopass  and  hipass  filter  as  well. 

must  be  greyscale  with  dimensions  =  power  of  2 

must  be  same  size  and  type  as  source 

lowest  passable  frequency 

highest  passable  frequency 


Binarize:  <source>  <destination>  <threshold> 


BINARIZE 

Source 

Destination 

Threshold 


-  sets  pixels  with  intensity  >=  threshold  to  255  and 
sets  pixels  with  intensity  <  threshold  to  0. 

-  must  be  greyscale 

-  must  be  same  type  and  size  as  source 

-  intensity  value  t  s.t.  0  <-  t  <“  255 


Block  Fill:  <window>  <xl>  <yl>  <x2>  <y2>  <i''r  [0]'>  <i^g  [0]>  <i^b  t03> 
Switches:  <i  ■  inverted  color> 


BLOCK  FILL 

Window 

XI 

yi 

X2 

y2 

Red 

Green 

Blue 

-i 


Fills  a  block  with  a  color. 

Blocks  extending  past  window  boundaries  are  clipped, 
may  be  greyscale  or  color. 

X  coordinate  of  corner  1 

y  coordinate  of  corner  1 

X  coordinate  of  corner  2  (opposite  corner  1) 

y  coordinate  of  corner  2  (opposite  corner  1) 

red  color  value 

green  color  value  (ignored  if  window  is  greyscale) 
blue  color  value  (ignored  if  window  is  greyscale) 
draw  block  in  inverted  color 

Do  not  provide  color  arguments  with  this  switch. 
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Change  Directory:  <directory> 

CHANGE  DIRECTORY  -  change  the  current  working  directory. 
Directory  -  a  UNIX  directory  pathnaune. 


Circle:  <window>  <xcenter>  <ycenter>  <radius>  <i''r  [0]>  <i^g  [0]>  <i^b  [0]> 
Switches:  <i  =  inverted  color> 


CIRCLE 

Window 
X  Center 
Y  Center 
Radius 
Red 
Green 
Blue 
-i 


-  Draws  a  circle  in  a  window. 

Circles  extending  past  window  boundaries  are  clipped. 

-  may  be  greyscale  or  color 

-  X  coordinate  of  center 

-  y  coordinate  of  center 

-  radius  in  pixels 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  draw  the  circle  in  inverted  color. 

Do  not  provide  color  arguments  with  this  switch. 


Clear  Window:  <window>  <b''r  [0]>  <b''g  tOJ>  <b^b  [0]> 
Switches:  <b  =  black> 


CLEAR  WINDOW 

Window 

Red 

Green 

Blue 

-b 


-  sets  every  pixel  in  a  window  to  a  color  you  specify. 

-  must  be  greyscale  or  color 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  set  window  to  black  (0,0,0) 

Do  not  provide  color  arguments  with  this  switch. 


Color  Threshold:  <src>  <dest>  <"bounds"  [see  help]>  <"colors"  [bmvcgyorw]> 


COLOR  THRESHOLD 

Source 

Destination 

Boundaries 


Colors 


-  partitions  an  image  into  9  colors. 

It  is  used  in  conjunction  with  PRINT  PICTURE. 

-  can  be  greyscale  or  color  but  in  either  case  only 
the  red  byte  is  used. 

-  must  be  color  and  must  match  the  size  of  the  source. 

-  a  quoted  list  of  two  to  ten  monotonically  increasing 
integers  that  partitions  a  greyscale  intensity  range 
The  first  integer  must  be  zero;  the  last  must  be  256. 

The  default  is;  "0  30  60  90  120  150  180  210  240  256" 

-  a  quoted  list  of  characters  indicating  the  color  to  which 
the  corresponding  intensity  partition  will  be  set. 

If  n  bounds  are  specified,  n-1  colors  must  be  specified. 
Permitted  colors  are:  (b)lack,  (m)ud,  (v)iolet,  (c)yan, 
(g)reen,  (y)ellow,  (o) range,  (r)ed,  (w)hite 
The  default  is:  "brovcgyorw" 


Complement:  <source>  <destination> 
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COMPLEMENT 


Source 

Destination 


transforms  the  intensity  of  each  pixel  in  an  image  to 
the  difference  between  the  pixel's  intensity  and 
the  maximum  intensity, 
must  be  greyscale  or  color 

must  have  same  type  and  dimensions  as  source 


Convert :  <window>  <newtype> 


CONVERT 


Window 
New  Type 


changes  a  window's  type  to  the  type  you  specify. 
Any  requisite  thresholding  must  be  completed 
before  calling  CONVERT,  eg  grey  to  binary. 

Real  images  are  normed  to  (0,255)  before 
being  converted  to  grey, 
no  restriction 

(b) inary,  (g)reyscale,  (c)olor,  or  (r)eal 


Copy  Window:  <source>  <destination> 


COPY  WINDOW  -  copies  the  contents  of  the  source  window  to  the  destination 

window.  If  the  destination  is  smaller  than  the  source, 
the  source  will  be  trucated.  If  the  destination  is  larger, 
then  any  unneeded  area  will  be  left  untouched. 

Source  -  no  restriction 

Destination  -  must  be  same  type  as  source 


Delete  Tsave:  <window> 

DELETE  TSAVE  -  deletes  a  tsave. 

Window  -  may  be  greyscale  or  color 

must  be  on  screen 


Delete  Window:  <window> 

DELETE  WINDOW  -  deallocates  a  window. 

Window  -  no  restriction 


Demo  Lambert:  <window>  <sx>  <sy>  <sz> 


DEMO  LAMBERT 

Window 
Source  X 
Source  Y 
Source  Z 


generate  image  of  cylinder  using  lambert's  law 

Assume  orthogonal  projection. 

must  be  greyscale 

real-valued  x  position  of  source 

real-valued  y  position  of  source 

real-valued  z  position  of  source 


DoG  Filter:  <source>  <destination>  <width>  <i^dc  [0.0] > 

Switches:  <i  -  interactive>  <o  -  off  center>  <p  -  positive  only> 
Switches:  <n  =  negative  onlv>  <a  -  absolute  value>  <s  -  signed> 
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DoG  FILTER 


Source 

Destination 


Width 
DC  term 

-i 

-o 

-P 

-n 

-s 

-a 

Note 


Convolves  a  difference  of  Gaussians  kernel  with  source. 
Approximates  a  Laplacian  of  a  Gaussian. 

By  default  the  kernel  is  on  center,  off  surround. 

Use  switch  -o  to  get  an  off  center,  on  surround  kernel, 
may  be  greyscale  or  color  window 
If  color  only  the  red  byte  is  used 

If  greyscale  window,  results  are  normalized  to  [-127,127] 

&  then  translated  to  [0,254]  so  that  zerocrossings 
have  value  127 

If  color  window,  then  zerocrossings  have  value  0 
Only  color  windows  can  accomodate  negative  values 
Distance  in  pixels  between  poi  of  inhibitory  gaussian 
Adjusts  the  volume  under  the  excitatory  gaussian 
Either  specified  by  argument  or  set  interactively  using  -i 
Set  the  DC  term  interactively. 

Change  kernel  to  off  center,  on  surround. 

Show  positive  values  only 
Show  negative  values  only 
Show  signs  only 
Take  absolute  value 

The  four  transformations  specified  by  the  switches  are 
performed  before  the  normalization  &  translation  of 
greyscale  destinations. 


Enhance  Contrast:  <source>  <destination> 


ENHANCE  CONTRAST 
Source 

Destination 


-  maximizes  the  intensity  differences  between  pixels. 

-  must  be  greyscale  or  color 

If  color  only  the  red  byte  is  used. 

-  must  be  same  type  and  size  as  source 


FFT  Image:  <source>  <destination> 
Switches:  <1  =  display  log (amplitude) > 


FFT  IMAGE 

Source 

Destination 

-1 


-  transforms  from  spatial  domain  to  frequency  domain 
and  displays  result  as  intesity  image 

-  must  be  greyscale  with  dimensions  -  power  of  2 

-  must  have  same  size  and  type  as  source 

-  display  logarithm  of  amplitude  rather  than  amplitude 


FFT  Plot:  <source>  <dest>  <start>  <end>  <a'‘xlb>  <a''xub>  <a''ylb>  <a''yub> 
Switches:  <a  -  auto-scale>  <f  -  fit  to  log(freq)>  <p  -  fit  to  log (power) > 
Switches:  <i  -  integer-valued>  <d  -  display  data>  <c  -  clear  destination> 


FFT  PLOT 

Source 

Destination 

Start 

End 

X  Lower  Bound 


X  Upper  Bound 


plot  frequency  vs  power  and  show  best  linear  fit 

must  be  greyscale 

must  be  greyscale 

first  data  point  to  plot 

last  data  point  to  plot 

lower  bound  on  x  data  va.lues 

required  to  compare  plots  across  images 

do  not  specify  with  -a 

upper  bound  on  x  data  values 

required  to  compare  plots  across  images 
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y  Lower  Bound 


Y  Upper  Bound 


-a 

-f 

-i 

-P 

-d 


do  not  specify  with  -a 

-  lower  bound  on  y  data  values 
required  to  compare  plots  across  images 
do  not  specify  with  -a 

-  upper  bound  on  y  data  values 
required  to  compare  plots  across  images 
do  not  specify  with  -a 

-  scale  automatically 

-  plot  log (frequency)  instead  of  frequency 

-  input  values  are  integer-valued,  not  grey- scale 

-  plot  log (power)  instead  of  power 

-  display  data  point  being  plotted 


Fourier  Fractal  Seg:  <source>  <dest> 

Switches:  <d  =  display  slopes> 

FOURIER  FRACTAL  SEG  -  the  Pentland  method  of  doing  fractal  segmentation. 

compute  fractal  dimension  for  each  8x8  square  by 
means  of  a  fourier  transform 

Source  -  must  be  greyscale  &  each  dimension  must  =  power  of  2 

Destination  -  must  be  same  type  and  size  as  source 


Fourier  OH  Curve:  <source>  <dest>  <ospace  [5]>  <start  [2]>  <end  [0]> 
Switches:  <a  »=  autoscale  radius>  <d  display  curve  pts> 


FOURIER  OH  CURVE 

Source 

Destination 

Orientation  Spacing 

Start 

End 

Radius  Scale 


plots  curve  of  orientation  vs  hausdorff  dimension 
must  be  greyscale  &  have  square  dimensions  =  power  of  2 
must  be  color 

spacing  of  samples  of  orientation  dimension  in  degrees 
first  data  point  to  plot 
last  data  point  to  plot 
factor  to  scale  radius  by 

Do  not  provide  this  argument  with  the  switch  -a. 


Frame :  <window> 

FRAME  -  draws  a  box  in  inverted  color  around  a  window. 

The  box  is  inclusive,  covering  the  edges  of  the  window. 
To  make  the  box  go  away,  simply  issue  FRAME  once  more. 
Window  -  may  be  greyscale  or  color 


Gabor  Filter: 


GABOR  FILTER 
Source 
Destination 
Temp  File 
Kernel  X  Size 
Kernel  Y  Size 


<source>  <dest>  <file> 

<kxsize  17] >  <kysize  [7]>  <sdevx  t2.0]>  <sdevy  [2.0]> 
<spatial_paving  (2]> 

<#octaves  [-1I>  <minperiod  [2.0]> 

<orient__paving  [30.0]>  <ofirst  [0]>  <olast  [5]> 

-  transforms  from  spatial  domain  to  info  hyperspace. 

-  must  be  greyscale  &  each  dimension  must  »  power  of  2 

-  must  be  same  size  and  type  as  source 

-  unique  file  prefix  for  temporary  files  written  to  disk. 

-  odd  integer  defining  size  in  pixels  of  kernel  width 

-  odd  integer  defining  size  in  pixels  of  kernel  height 
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X  Std  Dev 

Y  Std  Dev 

Spatial  Paving 
Number  of  Octaves 

Minimum  Period 


Orientation  Paving 

First  Orientation 
Last  Orientation 


real-valued  standard  deviation  in  pixels  per  deviation 
defines  the  x-axis  coverage  of  the  gaussian  envelope 
real-valued  standard  deviation  in  pixels  per  deviation 
defines  the  y-axis  coverage  of  the  gaussian  envelope 
rate  at  which  to  sample  image,  eg  3  =  every  third  pixel 
Number  of  levels  in  pyramid,  -1  means  use  the  maximum 
possible  levels.  Since  each  level  is  half  the  size  of 
the  level  below,  levels  are  each  one  octave  apart 
real-valued  minimum  period  sampled  in  pixels  per  cycle 
Its  inverse  is  the  frequency  sampled  at  the  lowest  level 
i.e.  the  highest  f request  sampled. 

Spacing  of  orientation  samples  in  degrees 
Must  divide  180  without  remainder, 
index  of  first  orientation 
index  of  last  orientation 


Gabor  Fractal  Seg:  <source>  <dest>  <ofirst>  <olast> 

Ocxsize  t7]>  <kysize  [7]>  <sdevx  [2.0]>  <sdevy  [2.0]> 
<spatial_paving  [2]> 

<#octaves  [-!]>  <minperiod  [2.0]> 

<orient_paving  [30.0]>  <ofirst  [0]>  <olast  [5]> 


GABOR  FRACTAL  SEG 
Source 
Destination 
Kernel  X  Size 
Kernel  Y  Size 
X  Std  Dev 

Y  Std  Dev 

Spatial  Paving  - 
Number  of  Octaves 


-  use  gabor  filter  to  compute  fractal  dimension 
must  be  greyscale 
must  be  greyscale 

odd  integer  defining  size  in  pixels  of  kernel  width 
odd  integer  defining  size  in  pixels  of  kernel  height 


real-valued  standard  deviation 
defines  the  x-axis  coverage  of 
real-valued  standard  deviation 
defines  the  y-axis  coverage  of 
rate  at  which  to  sample  image, 

-  Number  of  levels  in  pyramid. 
Since  each  level  is  half  the 


in  pixels  per  deviation 
the  gaussian  envelope 
in  pixels  per  deviation 
the  gaussian  envelope 
eg  3  =  every  third  pixel 
-1  means  max  possible  levels 
size  of  the  level  below 


levels  are  each  one  octave  apart 

Minimum  Period  -  real-valued  minimum  period  sampled  in  pixels  per  cycle 

Its  inverse  is  the  frequency  sampled  at  the  lowest  level 
ie  the  highest  f request  sampled. 

Orientation  Paving  -  Spacing  of  orientation  samples  in  degrees 

Must  divide  180  without  remainder. 

First  Orientation  -  index  of  first  orientation 
Last  Orientation  -  index  of  last  orientation 


Gabor  OH  Curve:  <source>  <dest> 


GABOR  OH  CURVE 

Source 

Destination 


-  plots  curve  of  orientation  vs  hausdorff  dimension 

-  must  be  greyscale 

-  must  be  greyscale 


Gaussian  Expand:  <source>  <dest> 

GAUSSIAN  EXPAND  -  uses  5x5  gausslan  kernel  to  expand  repeatedly  by  factor 

of  2  from  size  of  source  to  size  of  destination 

Source  -  must  be  greyscale  and  dx, dy  must  be  powers  of  two 

Destination  -  must  be  greyscale  and  dx,dv  must  be  powers  of  two 
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Gaussian  Filter:  <source>  <dest>  <width>  <dc  [0.0] > 
Switches:  <n  =  new  version> 


GAUSSIAN  FILTER  - 

Source 

Destination 


Width 
DC  term 
-n 


lo  pass  filters  an  image  using  a  gaussian. 
must  be  greyscale 

must  be  the  same  size  and  type  as  source 
The  results  are  normalized  to  [a,b], 

where  a  &  b  are  the  min  &  max  intensities  of  the  source, 
one  theory  says  this  is  the  distance  in  pixels  between  poi 
Adjusts  the  volume  under  the  gaussian. 

use  new  version  where  width  =  standard  deviation  in  pixels 


Gaussian  Reduce:  <source>  <dest> 


GAUSSIAN  REDUCE 

Source 

Destination 


-  uses  5x5  gaussian  kernel  to 
of  2  from  size  of  source  to 

-  must  be  greyscale  and  dx, dy 

-  must  be  greyscale  and  dx, dy 


reduce  repeatedly  by  factor 
size  of  destination, 
must  be  powers  of  two 
must  be  powers  of  two 


Get  ID :  <window> 

GET  ID  -  get  fractal  dimension  for  Id  image  using  FFT 

Window  -  must  be  greyscale,  uses  only  top  line 


Get  Picture:  <window>  <file> 


GET  PICTURE  -  gets  a  picture  from  a  hips  formatted  file  and  fits  it  into 

a  window. 

VUndow  -  no  restriction 

Color  windows  requires  a  triplet  of  files  (see  below) . 

File  -  name  of  file  matching  window  type 

If  window  is  color,  .r,  .g,  &  .b  will  automatically  be 
suffixed  to  the  file  name. 


Grey  Operations:  <source  1>  <op>  <source  2>  <destination> 
Switches;  <n  -  normallze> 


GREY  OPERATIONS 

Source  1 
Operation 

Source  2 

Destination 

-n 


performs  binary  operations  on  greyscale  windows  of 
identical  characteristics, 
must  be  greyscale 

One  of  addition (+),  subtract  '•nC-),  or(|),  exclusive  or(^), 
and(&),  multiplication (*) ,  dx vision (/) ,  distance (d). 
must  be  greyscale 

dimensions  must  match  those  of  source  1 
must  be  greyscale 

dimensions  must  match  those  of  source  1 
normalize  result  of  operation  instead  of  clipping 
only  use  with  addition,  subtraction,  multiplication,  and 
division 
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Grid:  <window>  <xspace>  <yspace>  <i''r  [0]>  <i''g  [0]>  <i''b  [0]> 
Switches:  <i  =  inverted  color> 


GRID 
Window 
X  Spacing 
Y  Spacing 
Red 
Green 
Blue 
-i 


-  draws  a  grid  over  a  window 

-  may  be  greyscale  or  color 

-  horizontal  spacing  between  grid  lines 

-  vertical  spacing  between  grid  lines 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  draw  the  grid  in  inverted  color. 

Do  not  provide  color  arguments  with  this  switch. 


Halftone:  <source>  <destination> 


HALFTONE 

Source 

Destination 


-  halftones  grey  areas  of  an  image,  ignoring  color  pixels 

-  must  be  greyscale  or  color 

-  must  be  same  type  and  size  as  source 


Help:  NO  ARGUMENTS 

HELP  -  Displays  system  help. 


Histogram:  <source>  <t^destination>  <c&clip> 

Switches:  <c  =  clip  hi  freq>  <t  =  terminal  only> 

HISTOGRAM  -  draws  a  histogram  of  the  source  in  the  destination 

and  prints  a  numerical  histogram  on  the  terminal  screen. 
The  numerical  histogram  is  both  unsealed  and  undipped. 

The  graphics  histogram  always  has  its  intensity  range 
scaled  to  fit  the  destination  window  width,  and  its 
frequency  range  is  always  scaled  to  fit  the  destination 
window  depth. 

Source  -  must  be  greyscale 

Destination  -  must  be  color  and  at  least  256  pixels  wide 

Percent  to  Clip  -  integer  percentage  (See  -c  below) 

Provide  only  if  using  -c. 

-c  -  Clip  the  highest  x  percent  of  frequencies,  e.g.  if  a 

total  of  10  different  frequencies  arise  in  the  histogram, 
clipping  the  highest  20  percent  means  that  the  graphics 
output  will  be  scaled  to  maximize  contrast  between  the  8 
lower  frequencies.  With  -c  you  must  specify  the  percentage 
as  an  additional  argument  in  integer  form. 

-t  -  Cancels  the  graphics  display. 

Do  not  specify  a  destination  window  with  this  switch. 


Info  Window:  <window> 

INFO  WINDOW  provides  information  about  a  given  window  in  the  format 
<Name,  X,  Y,  DX,  DY,  Type,  Updated,  Tsaved?> 

<Name>  window's  symbolic  name; 
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<X,  y>  coordinates  of  window's  top  left  hand  corner; 

<DX,  Dy>  window's  width  and  depth  in  pixels; 

<Type>  window  type:  Binary,  Grey,  Color,  or  Real 

<Updated>  tells  whether  the  window  is  updated  on  screen  or  in  core; 

<Tsaved?>  tells  whether  or  not  a  window  that  is  being  updated  on 

screen  has  a  copy  of  itself  stored  in  core. 

If  the  window  has  a  title,  that  also  is  displayed. 


Init  Display:  NO  ARGUMENTS 

INIT  DISPLAY  -  initializes  the  graphics  display  device. 


Integer  Operations:  <source  1>  <op>  <source  2>  <destination> 
Switches:  <g  =  make  greyscale> 


INTEGER  OPERATIONS 

Source  1 
Operation 

Source  2 

Destination 

-g 


performs  binary  operations  on  greyscale  windows  of 
identical  characteristics, 
must  be  color  or  greyscale 

One  of  addition (  +  ),  subtraction  (-) ,  or ( | ) ,  exclusive  or{^; 

and(&),  multiplication (*) ,  division (/),  distance (d). 

must  be  color  or  greyscale 

dimensions  must  match  those  of  source  1 

must  be  color  or  greyscale 

dimensions  must  match  those  of  source  1 

convert  result  of  operation  to  greyscale 


Interpolative  Zoom:  <source>  <destination>  <xzoom>  <yzoom> 


INTERPOLZATIVE  ZOOM 


Source 
Destination 
X  Zoom 
Y  Zoom 


expands  the  source  into  the  destination  using  bilinear 

interpolation.  If  the  destination  is  too  small,  the 

source  is  reduced.  If  the  destination  is  too  big, 

the  extra  area  is  untouched. 

may  be  greyscale  or  color 

may  be  greyscale  or  color 

real  zoom  factor  >  1.0 

real  zoom  factor  >  1.0 


Life:  <window>  <birth  min>  <birth  max>  <survival  min>  <survival  max>  <numgen> 


LIFE 

Window 

Birth  Min 
Birth  Max 
Survival  Min 
Survival  Max 
Num  Generations 


play  the  game  of  life 

must  be  greyscale,  must  be  on  screen,  and  must  contain 
the  initial  pattern 

minimum  number  of  neighbors  for  dead->live  transition 
maximum  number  of  neighbors  for  dead->live  transition 
minimum  number  of  neighbors  to  prevent  live->dead  transition 
maximum  number  of  neighbors  to  prevent  live->dead  transition 
number  of  generations 


Line:  <window>  <xl>  <yl>  <x2>  <y2>  <i''r  t0]>  <i''g  [0]>  <i^b  [0]> 
Switches:  <i  ••  inverted  color> 
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Scalel 

Phasel 

Powerl 

Scale2 

Phase2 

Powerl 


The  larger  the  size  the  better  the  generated  fractal 
will  match  the  specified  dimension. 

-  Size  of  1st  process  lobe  unless  -t  is  used,  in  which  case 
its  the  threshold  in  degrees. 

-  Orientation  of  1st  process  lobe. 

-  Eccentricity  of  1st  process  lobe. 

If  -t  specified,  powerl  =  #  degrees  sutended  by  pie  slices 

-  Size  of  2nd  process  lobe. 

-  Orientation  of  2st  process  lobe. 

-  Eccentricity  of  2st  process  lobe. 


Make  Window;  <name>  <x>  <y>  <xsize  [256] >  <ysize  [256] >  <type  [g]> 
Switches:  <c  =  make  in  core> 


MAKE  WINDOW 


Window  Name 
X  Position 

Y  Position 
X  Size 

Y  Size 


-c 


Type 


-  allocates  a  window  on  a  512  x  512  pixel  plane. 

The  top  left  corner  of  the  pixel  plane  is  (0,0) . 

There  are  no  constraints  on  position, 

i.e.  overlapping  other  windows  is  ok. 

-  a  unique  symbolic  name 

-  X  coordinate  of  top  left  corner  in  screen  coordinates 

-  y  coordinate  of  top  left  corner  in  screen  coordinates 

-  width  in  pixels 
The  default  is  256. 

-  height  in  pixels 
The  default  is  256. 

-  Update  the  window  in  core . 

Must  be  used  if  the  Menu  System  was  called  with  the 
core  switch  (-c) . 

-  (b) inary,  (g)reyscale,  (c)olor,  or  (r)eal 
The  default  is  greyscale. 


Median  Filter:  <source>  <destination>  <xsize>  <ysize>  <  (ai) ''"sampling"> 
Switches:  <i  =  interactive>  <a  =  all  pixels  sampled> 


MEDIAN  FILTER 
Source 
Destination 
X  Size 
Y  Size 

Sampling  Scheme  - 


-i 


-a 


applies  a  median  filter  good  for  reducing  spot  noise 
must  be  greyscale 

must  be  same  size  and  type  as  source 
horizontal  width  of  kernel 
vertical  width  of  kernel 

a  quoted  string  specifying  the  pixels  that  the  filter  will 
sample  to  determine  the  median  of  the  region  it  covers . 

The  string  must  only  contain  ones  and  zeroes,  where  a  one 
indicates  that  an  element  will  be  sampled  and  a  zero 
indicates  that  it  will  not.  eg:  a  3x3  filter  that  samples 
the  first  and  third  columns  would  be  given  by  "101101101" 
and  a  5  X  3  filter  sampling  the  first  and  third  rows  would 
be  described  by  "111110000011111". 

-a  &  -i  also  let  you  specify  the  sampling  scheme. 

Lets  you  toggle  filter  elements  on  or  off  using  a  cursor. 
Do  not  provide  a  sampling  scheme  argument  with  this  switch 
Indicates  that  all  pixels  will  be  sampled. 

Do  not  provide  a  sampling  scheme  argument  with  this  switch 


Mouse  Block  Fill:  <window>  <i^r  [0]>  <i''g  [0]>  <i^b  [01> 
Switches:  <i  “  inverted  color> 
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LINE 

Window 

XI 

yi 

X2 

Y2 

Red 

Green 

Blue 


draws  a  line  in  a  window. 

Lines  extending  past  window  boundaries  are  clipped, 
may  be  greyscale  or  color 
X  coordinate  of  first  endpoint 
y  coordinate  of  first  endpoint 
X  coordinate  of  second  endpoint 
y  coordinate  of  second  endpoint 
red  intensity 

green  intensity  (ignored  if  window  is  greyscale) 
blue  intensity  (ignored  if  window  is  greyscale) 
draw  line  in  inverted  color 

Do  not  provide  color  arguments  with  this  switch. 


List  Windows :  NO  ARGUMENTS 


LIST  WINDOWS  provides  information  about  each  window  in  the  format 
<Name,  X,  Y,  DX,  DY,  Type,  Updated,  Tsaved?> 

<Name>  window's  symbolic  name; 

<X,  Y>  coordinates  of  window's  top  left  hand  corner; 

<DX,  DY>  window's  width  and  depth  in  pixels; 

<Type>  window  type:  Binary,  Grey,  Color,  or  Real 

<Updated>  tells  whether  the  window  is  updated  on  screen  or  in  core; 

<Tsaved?>  tells  whether  or  not  a  window  that  is  being  updated  on 

screen  has  a  copy  of  itself  stored  in  core. 

The  command  INFO  WINDOW  provides  more  data  about  a  specific  window. 

A  count  of  windows  used  and  unused  is  also  provided. 


Make  ID  Fractal:  <window>  <dimension>  <sample  [8192] >  <offset  [0]> 
Switches:  <1  =  line  texture>  <r  =  reproducible> 


MAKE  ID  FRACTAL 


Window 
Dimension 
Sample  Si2e 


Freq  Offset 
-1 
-r 


generate  ID  fractal  texture  by  filtering 

ID  real  white  noise  in  the  frequency  domain 

The  output  is  a  graph  of  position  vs  elevation. 

must  be  greyscale 

1.0  <=  fractal  dimension  <  2.0 

the  size  of  the  white  noise  sample 

Must  be  a  power  of  two  because  of  FFT. 

The  larger  the  size  the  better  the  generated  fractal 
index  of  lowest  displayed  frequency 
generate  line  texture  instead  of  graph 
generate  reproducible  random  noise 


Make  2D  Fractal:  <window>  <dim>  <sample  [512] >  <sl>  <pl>  <el>  <s2>  <p2>  <e2> 
Switches:  <a  “  one  lobed  process>  <b  -  two  lobed  processes> 

Switches:  <t  -  threshold  process>  <o  *  original  output>  <z  =  zeromin  output> 
Switches :  <s  «  scaledown  output>  <n  -  non-reproducible> 


MAKE  2D  FRACTAL 


Window 
Dimension 
Sample  Size 


make  2D  fractal  texture  by  filtering  2D  real  white  noise 

in  the  frequency  domain.  By  default  the  fractal  will  be 

isotropic;  use  the  switches  to  make  anisotropic  fractals. 

The  texture  is  presented  as  an  intensity  map. 

must  be  greyscale 

2.0  <-  fractal  dimension  <  3.0 

the  size  of  the  white  noise  sample 

Must  be  a  power  of  two  because  of  FFT. 
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MOUSE  BLOCK  FILL  - 

Window 

Red 

Green 

Blue 


fill  a  block  within  a  window  with  a  color 

Use  the  mouse  to  select  two  diagonally  opposed  corners. 

must  be  color  or  greyscale. 

red  color  value 

green  color  value  (ignored  if  window  is  greyscale) 
blue  color  value  (ignored  if  window  is  greyscale) 
draw  block  in  inverted  color 

Do  not  provide  color  arguments  with  this  switch. 


Mouse  Block  Read:  <window> 

MOUSE  BLOCK  READ  -  lets  you  define  a  block  within  a  window  and  examine 

the  coordinates  and  intensities  of  each  pixel  in  the 
block.  Use  the  mouse  to  select  two  diagonally  opposed 
corners . 

Window  -  must  be  color  or  greyscale. 


Mouse  Cross-section:  <source>  <destination> 

MOUSE  CROSS-SECTION  -  lets  you  view  plots  of  greyvalue  along  cross-sections 

of  an  image. 

Source  -  must  be  greyscale 

Destination  -  must  be  color,  at  least  256  pixels  high,  and  at  least 

as  wide  as  the  largest  dimension  of  the  source. 


Mouse  Dots:  <window>  <r  [0]>  <g  [0]>  <b  [0]> 


MOUSE  DOTS 

Window 

Red 

Green 

Blue 


-  lets  you  draw  dots  in  a  window  using  a  mouse 

-  may  be  greyscale  or  color 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 


Mouse  Drag  New  Window:  <name>  <xsize  [256] >  <ysize  [256] >  <type  [g]> 


MOUSE  DRAG  NEW  WINDOW  - 


Window  Name 
X  Size 
y  Size 
Type 


allocates  a  window  on  a  512  x  512  pixel  plane. 

Use  the  mouse  to  move  the  window  frame  around  the 
screen  by  one  corner.  You  can  change  the  corner  that 
the  mouse  selects.  There  are  no  constraints  on 
position,  i.e.  overlapping  other  window  is  ok. 

The  window  cannot  be  created  in  core, 
a  unique  symbolic  name 
width  in  pixels.  The  default  is  256. 
height  in  pixels.  The  default  is  256. 

(g)reyscale  or  (c)olor.  The  default  is  greyscale. 


Mouse  Jagged  Line:  <window>  <i''r  [0]>  <i^g  [0]>  <i''b  [0]> 
Switches:  <i  -  inverted  color> 


MOUSE  JAGGED  LINE  -  lets  you  draw  a  an  unlimited  number  of  connected  line 
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Window 

Red 

Green 

Blue 

-i 


segments  in  a  window  using  a  mouse. 

-  may  be  greyscale  or  color 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  use  inverted  color 

Do  not  specify  colors  with  this  switch. 


Mouse  Make  Window:  <name>  <type  (g]> 


MOUSE  MAKE  WINDOW  - 


Window  Name 
Type 

Note 


allocates  a  window  on  a  1024  x  1024  pixel  plane. 

Use  the  mouse  to  select  two  opposing  corners  of  the 
new  window . 

a  unique  symbolic  name 

(b) inary,  (g)reyscale,  (c)olor,  or  (r)eal 
The  default  is  greyscale. 

The  top  left  corner  of  the  pixel  plane  is  (0,0) . 
There  are  no  constraints  on  position, 
i.e.  overlapping  other  windows  is  ok. 

The  window  cannot  be  created  in  core . 

The  window  is  framed  after  creation;  you  may  remove 
the  box  using  FRAME. 


Mouse  Pixel  Read:  <window> 

MOUSE  PIXEL  READ  -  lets  you  retrieve  the  window  coordinates  and  color  of  the 

pixel  under  the  cursor. 

Window  -  must  be  greyscale  or  color 


Mouse  Polygon:  <window>  <i''r  [0]>  <i^g  [0]>  <i'"b  [0]> 
Switches:  <i  =  inverted  color> 


MOUSE  POLYGON 

Window 

Red 

Green 

Blue 

-i 


-  lets  you  draw  a  polygon  in  a  window  using  a  mouse. 

-  may  be  greyscale  or  color 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  use  inverted  color 

Do  not  specify  color  values  with  this  switch. 


Mouse  Spline:  <window>  <i''r  [0]>  <i^g  [0]>  <i^b  [0]> 
Switches:  <i  -  inverted  color> 


MOUSE  SPLINE 

Window 

Red 

Green 

Blue 

-i 


-  lets  you  use  a  mouse  to  connect  knot  points  with  a  spline. 

-  may  be  greyscale  or  color 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  draw  curve  in  inverted  color 

Do  not  provide  color  arguments  with  this  switch. 
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Mouse  Straight  Line:  <window>  <i^r  [0]>  <i''g  [0]>  <i^b  [0]> 
Switches;  <i  =  inverted  color> 


MOUSE  STRAIGHT  LINE  -  lets  you  draw  an  unlimited  number  of  straight  lines 

in  a  window  using  a  mouse. 

Window  -  may  be  greyscale  or  color 

Red  -  red  intensity 

Green  -  green  intensity  (ignored  if  window  is  greyscale) 

Blue  -  blue  intensity  (ignored  if  window  is  greyscale) 

-i  -  use  inverted  color 

Do  not  specify  color  values  with  this  switch. 


Print  Picture:  <window>  <print  file> 

Switches:  <w  =  write  file  only> 

PRINT  PICTURE  -  dumps  a  window's  contents  to  a  print  file,  which  is  then 

spooled  to  a  graphics  printer.  The  print  file  may  be 
deleted  any  time  after  is  spooled  to  the  printer. 

Ma)ce  sure  a  color  ribbon  is  in  the  printer. 

Window  -  may  be  color  or  greyscale 

If  greyscale,  the  printer  output  is  monochrome, 
otherwise  it  is  color. 

Print  File  -  the  name  of  the  file  to  which  the  picture  will  be  dumped. 

-w  -  dump  the  picture  to  the  print  file  but  do  not  spool  it. 


Put  Picture:  <window>  <file> 

Switches:  <o  =  overwrite  file>  <r  =  write  red  byte  only> 


PUT  PICTURE 

Window 

File 


-o 


-r 


-  writes  a  image  to  a  file  on  disk. 

-  no  restriction 

-  name  of  file 

If  the  picture  is  color  and  -r  is  NOT  used 
then  the  file  name  provided  will  be 
automatically  prefixed  to  .r,  .g,  and  .b. 

-  Overwrite  an  existing  file. 

-  Write  red  byte  only. 

Can  be  used  only  with  color  windows. 


Quit :  NO  ARGUMENT.*' 

QUIT  -  Resets  the  terminal  screen,  closes  the  scriptfile  if  it 

is  open  and  returns  you  to  the  operating  system. 


Random  Binary  Image:  <window> 

Switches:  <r  ■  reproducible> 

RANDOM  BINARY  IMAGE  -  create  a  random  binary  image 
Window  -  must  be  greyscale 

-r  -  generate  reproducible  pattern 


Rectangle:  <window>  <xl>  <vl>  <x2>  <v2>  <i''r  [0]>  <i‘'g  [0)>  <i^b  [0]> 
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Switches:  <i  =  inverted  color> 


RECTANGLE 

Window 
X  1 

y  1 

X  2 

Y  2 

Red 

Green 

Blue 

-i 


-  draws  a  rectangle  with  a  color. 

Rectangles  extending  past  window  boundaries  are  clipped. 

-  may  be  greyscale  or  color 

-  X  coordinate  of  corner  1 

-  y  coordinate  of  corner  1 

-  X  coordinate  of  corner  opposite  to  corner  1 

-  y  coordinate  of  corner  opposite  to  corner  1 

-  red  intensity 

-  green  intensity  (ignored  if  window  is  greyscale) 

-  blue  intensity  (ignored  if  window  is  greyscale) 

-  draw  the  circle  in  inverted  color. 

Do  not  provide  color  arguments  with  this  switch. 


Refresh:  NO  ARGUMENTS 

REFRESH  -  refreshes  the  terminal  display. 


Replace  Color:  <src>  <dest>  <rl[0]>  <gl[0)>  <bl[0]>  <r2[0]>  <g2[0]>  <b2[0]> 


REPLACE  COLOR 
Source 
Destination 
Current  Red 

Current  Green 

Current  Blue 

New  Red 

New  Green 

New  Blue 


sets  every  pixel  of  color  1  to  color  2. 

must  be  greyscale  or  color 

must  be  same  type  and  size  as  source 

red  intensity  of  color  1 

Specify  -1  to  match  any  red  value. 

green  intensity  of  color  1  (ignored  if  window  is  greyscale) 
Specify  -1  to  match  any  green  value. 

blue  intensity  of  color  1  (ignored  if  window  is  greyscale) 
Specify  -1  to  match  any  blue  value, 
red  intensity  of  color  2 

Specify  -1  to  leave  a  pixel's  red  byte  unchanged. 

green  intensity  of  color  2  (ignored  if  window  is  greyscale) 

Specify  -1  to  leave  a  pixel's  green  byte  unchanged. 

blue  intensity  of  color  2  (ignored  if  window  is  greyscale) 

Specify  -1  to  leave  a  pixel's  blue  byte  unchanged. 


Replicative  Zoom:  <source>  <destination>  <xzoom>  <yzoom> 

REPLICATIVE  ZOOM  -  does  a  replicative  integer  zoom.  The  source  window  is 

expanded  into  the  destination  window  by  replicating  pixels 
in  the  X  and  Y  directions.  If  the  destination  window  is  too 
small,  the  source  is  reduced.  If  the  destination  is  too 
big,  the  extra  area  is  untouched. 

-  may  be  greyscale  or  color 

-  must  be  same  type  as  source 

-  integer  scale  factor  >  0 

-  integer  scale  factor  >  0 


Source 
Destination 
X  Zoom 
Y  Zoom 


Rotate  90:  <source>  <dest> 


ROTATE  90 
Source 


-  rotate  image  90  degrees  cloc)cwise 

-  must  be  sguare 
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Destination  -  must  be  same  type  and  size  as  source 


Run  Script:  <script  file> 

Switches:  <e  =  echo  <i  =  interactive>  <a  =  abort  on  error> 


RUN  SCRIPT 

Script  File 

-e 

-i 

-a 


-  executes  a  script  file  during  an  interactive  session. 

-  script  file  to  run 

-  Echo  script  commands  to  screen. 

-  Allow  user  interaction  (eg  activate  more  filter) . 

-  Abort  on  script  file  error. 


Scale  Pixels:  <source>  <destination>  <scale  factor> 


SCALE  PIXELS 


Source 
Destination 
Scale  Factor 


-  scales  the  value  of  each  pixel  by  factor 

ie  (pixel  =  pixel  *  factor)  and  then  clips  the  result 
to  [0,255] 

-  must  be  greyscale 

-  must  have  same  type  and  dimensions  as  source 

-  real-valued  amount  by  which  to  scale  each  pixel 


Script  Off:  NO  ARGUMENTS 

SCRIPT  OFF  -  turns  off  the  recording  mechanism  and  prints 

the  number  of  lines  written  to  the  script  file. 


Script  On:  <file> 


SCRIPT  ON 


File 


-  turns  on  a  recording  mechanism  that  writes  each  successfully 
executed  command  line  to  a  file  on  disk.  The  command  line 
will  be  saved  even  if  you  are  prompted  for  arguments.  If  a 
command  line  contains  enough  arguments  to  invoke  a  routine 
several  times  then  the  script  file  will  contain  a  line  for 
each  invocation,  eg:  entering  "tsavs:  wl  w2"  will  result 

in  two  lines,  "tsave;  wl"  and  "tsave:  w2"  being  written 
to  the  script  file. 

Command  lines  beginning  with  the  comment  character  '#'  will 
be  written  to  the  file.  However,  comments  on  a  line 
containing  an  actual  command  will  be  disregarded  and 
therefore  not  recorded. 

-  file  to  write  to 

If  file  exists,  it  is  overwritten. 


Set  Environment:  <"variable">  <"value"> 


SET  ENVIRONMENT 

Variable 

Value 


-  allows  you  to  change  environment  variables. 

use  SHOW  ENVIRONMENT  to  get  the  variable  names  and 
sample  values 

-  quoted  string  naming  the  environment  variable 

-  quoted  string  that  will  become  the  variable's  new  value 


75 


Show  Environment :  NO  ARGUMENTS 

SHOW  ENVIRONMENT  -  displays  the  value  of  every  environment  variable. 


Show  Title;  <window>  <xpos>  <ypos>  <r  t0]>  <g  [0]>  <b  [0]> 
Switches:  <v  =  vertical> 


SHOW  TITLE 

Window 
X  Position 
Y  Position 
Red 
Green 
Blue 

-V 


writes  a  window's  title  to  the  graphics  display. 

Currently  clipping  is  not  performed. 

may  be  greyscale  or  color 

X  coordinate  of  top  left  corner 

y  coordinate  of  top  left  corner 

red  intensity 

green  intensity  (ignored  if  window  is  greyscale) 
blue  intensity  (ignored  if  window  is  greyscale) 
Write  the  text  vertically. 


Snap :  <window> 

SNAP  -  This  a  no-op  for  the  RASTECH. 


Statistics:  <window> 

STATISTICS  -  find  the  min,  max,  mean,  standard  deviation, 

variance,  s)cewness,  and  kurtosis  of  a  window. 
Window  -  must  be  greyscale 


Subsampling  Reduce:  <source>  <dest> 

SUBSAMPLING  REDUCE  -  subsamples  source  by  factor  of  2  to  produce 

destination 

Source  -  must  be  greyscale  and  dx,dy  must  be  powers  of  two 

Destination  -  must  be  greyscale  and  dx,dy  must  be  powers  of  two 


Superimpose:  <mask>  <foreground>  <background>  <destination> 


SUPERIMPOSE 


Mask 

Foreground 

Background 

Destination 


-  places  a  foreground  over  a  background  according  to  a  mask. 
If  the  value  of  a  mask  pixel  is  i55,  a  foreground  pixel 
is  written  to  destination.  If  the  mask  pixel  is  0,  a 
background  pixel  is  written. 

-  may  be  greyscale  or  color 

-  Must  be  same  size  and  type  as  mask 

-  Must  be  same  size  and  type  as  mask 

-  Must  be  same  size  and  type  as  mask 


Text:  <window>  <xpos>  <ypos>  <r  [0]>  <g  [0]>  <b  [0]>  <t^"text"> 
Switches;  <v  -  vertical>  <t  -  title> 
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TEXT 

Window 

X  Position 
y  Position 
Red 
Green 
Blue 

Text  String 

-V 

-t 


writes  a  string  to  the  screen. 

Clipping  is  not  performed, 
may  be  greyscale  or  color 
must  be  on  screen 

X  coordinate  of  top  left  corner  of  text  block 
y  coordinate  of  top  left  corner  of  text  block 
red  intensity 

green  intensity  (ignored  if  window  is  greyscale) 
blue  intensity  (ignored  if  window  is  greyscale) 
text  to  print,  must  be  in  quoted. 

Write  the  text  vertically. 

Use  the  window's  title  as  the  text. 


Thin:  <source>  <destination>  <signal>  <background>  <threshold> 


THIN 


Source 


Destination 
Signal 
Background 
Threshold  Size 


Given  a  binary  image,  delete  blobs  that  are 
smaller  than  a  threshold.  Blob  sizes  are  determined 
assuming  8-way  connectivity. 

Assumed  to  be  a  greyscale  image  comprised  of  pixels  that 

have  the  the  values  signal  or  background.  Any  pixels 

having  other  values  are  treated  as  background  pixels 

for  the  purpose  of  counting  blob  sizes  but  are  displayed 

with  their  original  values  in  the  destination. 

must  be  same  size  and  type  as  source 

color  of  blobs  to  threshold 

background  color 

blob  size  threshold  in  pixels 


Threshold:  <window>  <lower  bound>  <upper  bound>  <c&greyval> 
Switches:  <b  =  function  b>  <c  =  function  c>  <s  =  skip  color> 


THRESHOLD 


Window 
Lower  Bound 
Upper  Bound 
Greyval 

-b 

-c 

-s 

Note 


applies  one  of  three  threshold  functions  to  a  greyscale 
image.  All  functions  require  that  the  greyscale  range 
be  partitioned  into  three  regions, 
must  be  greyscale 

Partitions  the  first  and  second  regions. 

Partitions  the  second  and  third  regions. 

Greyval  to  which  regions  2  will  be  set  if  using  function  c, 
Provide  this  argument  only  if  using  -c. 

Use  function  b. 

Use  function  c. 

Skips  over  pixels  that  are  not  greyscale. 

The  functions  are  described  below. 


Function 

Switch 

Region  1 

0  <“  X  <  LB 

Region  2 

LB  <-  X  <“  UB 

Region  3 

UB  <  X  <-  255 

a 

none 

set  to  0 

set  to  255 

set  to  0 

b 

-b 

set  to  0 

unchanged 

set  to  255 

c 

-c 

unchanged 

set  to  greyval 

unchanged 

To  Core :  <window> 

Switches:  <o  -  overwrite  a  tsave>  <t  »  use  tsave  as  contents> 

TO  CORE  -  switches  a  window  from  being  updated  on  screen 

to  being  updated  in  core. 
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Window 

\  -o 
-t 

I 


-  may  be  greyscale  or  color 
must  be  on  screen 

-  Overwrite  the  tsave  if  it  exists. 

-  Use  the  tsave  (if  it  exists)  as  the  new  window  contents. 


To  Screen:  <window>  <s‘'xpos>  <s‘'ypos> 
Switches:  <s  =  use  same  <x,  y» 


TO  SCREEN 

Window 

Xpos 

Ypos 

-s 


switches  a  window  from  being  updated  in  core 
to  being  updated  on  screen, 
may  be  greyscale  or  color 
must  be  in  core 

X  position  of  top  left  corner  in  screen  coordinates 
y  position  of  top  left  corner  in  screen  coordinates 
Use  the  same  top  left  corner  that  is  already  stored. 


Translate  Pixels:  <source>  <destination>  <translation  factor> 


TRANSLATE  PIXELS 

Source 

Destination 

Translation 


-  computes  pixel  =  pixel  +  translation  factor 
and  then  clips  the  result  to  [0,255] 

-  must  be  greyscale 

-  must  have  same  type  and  dimensions  as  source 

-  integer  amount  by  which  to  translate 


Trestore:  <window> 


TRESTORE 


Window 


-  replaces  a  window's  screen  contents  with  the  window's 
last  tsave.  A  tsave  is  a  TEMPORARY  save  used  to  save  a 
window' s  contents  to  core  in  case  future  changes  to  the 
window  need  to  be  undone. 

-  may  be  greyscale  or  color 
must  be  on  screen 


Trim:  <window>  <xthick>  <ythick>  <i''r  (0]>  <i^g  [0]>  <i''b  [0]> 
Switches:  <i  =  inverted  color> 


TRIM 

Window 
X  Thickness 
Y  Thickness 
Red 

4  Green 
Blue 
•  -i 


Draws  a  border  around  a  window,  but  on  the  inside. 

Useful  for  hiding  edge  effects. 

may  be  greyscale  or  color 

width  in  pixels  of  left  and  right  borders 

width  in  pixels  of  top  and  bottom  borders 

red  intensity 

green  intensity  (ignored  if  window  is  greyscale) 
blue  intensity  (ignored  if  window  is  greyscale) 
draw  border  in  inverted  color 

Do  not  provide  color  arguments  with  this  switch. 


Tsave:  <window> 

Switches:  <o  -  overwrite  old  tsave> 
t  TSAVE 


-  saves  a  window's  contents  to  core  (volatile  memory). 
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This  is  a  TEMPORARY  save  used  to  save  a  window's 
contents  in  case  future  changes  to  the  window  need  to  be 
undone . 

Use  TRESTORE  to  copy  a  tsave  back  onto  the  screen. 

Window  -  may  be  greyscale  or  color 

must  be  on  screen 

-o  -  overwrite  any  existing  tsave  of  the  window 


Verify  Fractal:  <source>  <destination> 


VERIFY  FRACTAL 

Source 

Destination 


use  second  order  statistics  to  see  if  image  is  fractal 
must  be  greyscale 
must  be  512x512 


Wedge :  <window> 

WEDGE  -  Replaces  a  window's  contents  with  a  gradient  changing 

column  by  column  from  0  to  255.  If  there  are  more  than  256 
columns  in  the  window  the  gradient  repeats  starting  at  0. 
Window  -  may  be  greyscale  or  color 


White  Noise:  <window> 


WHITE  NOISE  -  fill  an  image  with  white  noise  in  the  range  [0,255] 

Window  -  must  be  greyscale 


Zerocrossings :  <source>  <destination> 


ZEROCROS SINGS 


Source 


Destination 


-  applies  the  following  transformations  to  isolate 


zerocrossings  found  by  a  DoG  Filter. 
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-  may  be  greyscale  or  color 

If  color  zerocrossings  are  assumed  to  have  value  0. 

If  greyscale  zerocrossings  are  assumed  to  have  value  127. 

-  must  be  greyscale. 
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